[LEDE-DEV] buildbot failure to compile because it lacks gtime host tool

[Alberto Bursi]

It seems that after the commit that added gtime as host dependency the 
buildbot failed to compile this target 
https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/


and all logs state that it is missing "gtime". I suppose that this will 
block compilation of any other target, eventually.


Can someone please install that tool in the buildbot so it will compile 
again?


Or maybe make the gtime an optional thing, as it was mostly supposed to 
be used for statistics in the patch I've seen from the thread


[LEDE-DEV] [PATCH v2] build: log time taken by each packages/steps

-Alberto


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

Re: [LEDE-DEV] OFF: openwrt.org down?

[Alberto Bursi]

On 07/05/2018 13:21, Levente wrote:

lev@mercury:~$ nslookup openwrt.org
;; Got SERVFAIL reply from 10.0.99.111, trying next server
Server:10.0.99.99
Address:10.0.99.99#53

** server can't find openwrt.org: SERVFAIL

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


They changed their main DNS servers, you can't access the site until 
your DNS provider has refreshed their lists to reflect this change.


I had the same issue on my tethering connection, I set up manual IP and 
set OpenDNS as DNS server (which is usually better than whatever default 
DNS you might have on your device)

208.67.222.222
and fallback
208.67.222.220

like I do on my home network, now I can reach openwrt.org.

-Alberto



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

Re: [LEDE-DEV] 18.06 Status?

[Alberto Bursi]

This isn't a job where you can force people to do anything.

Also, I'm not a fan of half-assing or leaving out things for the sake of 
a schedule.



-Alberto

On 05/05/2018 20:41, Fernando Frediani wrote:
One characteristic from OpenWrt, different from other projects is the 
lack of a leader or a person who can gather others together, make some 
decisions or push for them to happen. If one doesn't like this title 
it can also be "Project Manager" or "Project Coordinator". This, in my 
view, makes a big difference for things to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules (https://openwrt.org/rules) 
and add something to make it exist in benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen 
 wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:
I think that the main source tree is in pretty good shape, so 
branching

off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and 
rather than

focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some 
heart ache
when such decisions are made, but at a point those decisions do need 
to be
made. Without an official release to punctuate both the core team 
and other

packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be 
considered.


- Eric


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

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



___
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] prereq-mk: Change wget dependency to curl one.

[Alberto Bursi]

On 3/10/2018 7:13 PM, Stijn Segers wrote:


Op za, 10 mrt 2018 om 7:03 , schreef Rosen Penev :

On Sat, Mar 10, 2018 at 3:31 AM, Bjørn Mork  wrote:

 Rosen Penev  writes:


 curl is more common than GNU wget is.


 No.

Yes.



 For example, Cygwin, Arch Linux, and my android phone all come with
 curl by default whereas wget is missing.


 wget has priority "important" in Debian, while curl is "optional".

 I don't think it makes much sense to tune the installation system for
 some weird distros no one actually use to build OpenWrt.

Arch Linux is what I use to build OpenWrt.


Arch users might catch the edge cases (notably the bleeding edge 
ones). Debian based
systems tend to be more widespread than Arch ones, and running one or 
the other does
not imply a more skilled user either way. Our wiki buildroot 
instructions seem to
assume/favour a Debian-based system (that of course heavily depends on 
who wrote the

entry) [1].
...
[1] https://wiki.openwrt.org/doc/howto/buildroot.exigence



That's the old (archived, read-only) wiki link.

The new wiki article has no such favoring to Debian/buntu, and if you 
scroll down (in both articles actually) you find a list of CLI commands 
to install needed packages for most common distros. [1]
In the Arch one there is also wget in the list of packages to 
download/install, so if the Arch user is following the documentation he 
should have wget in his system.


[1] 
https://openwrt.org/docs/guide-developer/build-system/install-buildsystem



-Alberto

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

Re: [LEDE-DEV] [PATCH] busybox: re-enable telnet applet

[Alberto Bursi]

On 02/18/2018 10:21 PM, edgar.sol...@web.de wrote:

On 2/18/2018 21:26, Philip Prindeville wrote:

On Feb 18, 2018, at 11:25 AM, Philip Prindeville 
 wrote:




On Feb 18, 2018, at 2:27 AM, John Crispin  wrote:




On 20/06/17 19:13, Stefan Tomanek wrote:
While sshd should be favoured over telnetd, having a telnet client on the
router is useful for connecting to other devices in the same LAN.

Signed-off-by: Stefan Tomanek 

sorry for the late reply, it has been discussed over and over and the decision 
was made to not enable telnet by default. sorry ...

John

Too bad.  While it’s a liability for logging in, it’s a great tool for testing 
remote services like HTTP, SMTP, IMAP, JetDirect printers, etc.

SNIP

looks like it is possible to keep the telnet applet only, not telnetd. if this 
is not wanted for size, is there an alternative to interact with a port 
pushing/receiving characters?

..ede

___



There is a closed (not merged) PR for the packages repo that adds 
telnet-bsd package, which is a commonly used telnet client, and is 
independent from Busybox. The code is still available, and should work fine.

https://github.com/openwrt/packages/pull/4509

-Alberto

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

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Alberto Bursi]

On 02/14/2018 10:53 PM, David Woodhouse wrote:

On Wed, 2018-02-14 at 22:51 +0100, Alberto Bursi wrote:

Just change the WAN ssh port number to something in the dynamic port
range, pretty much 0 bots scan beyond the few well-known ports
range, and you save CPU resources too.

We're talking about the default config here though. Please let's not
encourage bogus security-through-obscurity measures in that context.


Your firewall rules weren't about security either but about twarting 
dumb bots doing internet-wide scans.
And for that I think there are better ways that also save CPU resources, 
as I said.


The security here still comes from having ssh using a key instead of a 
password, or at the very least a very good password. (although I still 
think the key is much better)


I quite frankly don't see why the default config should even enable ssh 
on WAN at all (apart from special cases on some devices that only have 
one port maybe), if the user wants to he should set it up on his own.


-Alberto

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

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Alberto Bursi]

On 02/14/2018 10:36 PM, David Woodhouse wrote:

On Wed, 2018-02-14 at 12:34 -0700, Philip Prindeville wrote:

Once I was messing with firewall settings and accidentally disabled
the firewall.  Within a few minutes, there were all sorts of password
attacks on the WAN port.  Having a sufficiently complex password
slowed things down long enough for me to re-secure the box.

Pfft. If you had a half-decent password, the box was always secure.

If you really care, perhaps roll something like this (which I have in
my /etc/firewall.user) into the default configuration:

for PROTO in iptables ip6tables ; do
    for TABLE in forwarding_rule input_rule; do
   $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --rcheck --hitcount 
4 --seconds 60 -j LOG --log-prefix "SSH_BRUTE "
   $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --update 
--hitcount 4 --seconds 60 -j REJECT --reject-with tcp-reset
   $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --set -j 
RETURN
    done
done

You have the same "problem" with external access via HTTPS, surely? Are
you planning to ban password access to that too?



Just change the WAN ssh port number to something in the dynamic port 
range, pretty much 0 bots scan beyond the few well-known ports range, 
and you save CPU resources too.


-Alberto

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

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Alberto Bursi]

On 14/02/2018 04:53, Philip Prindeville wrote:

On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:

On 9 February 2018 at 08:28, Philip Prindeville
 wrote:

From: Philip Prindeville 

Allowing password logins leaves you vulnerable to dictionary
attacks.  We disable password-based authentication, limiting
authentication to keys only which are more secure.

Note: You'll need to pre-populate your image with some initial
keys. To do this:

1. Create the appropriate directory as "mkdir -p files/root/.ssh"
   from your top-level directory;
2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
   "files/root/.ssh/authorized_keys" and indeed, you can collect
   keys from several sources this way by concatenating them;
3. Set the permissions on "authorized_keys" to 644 or 640.


If forgetting doing this means I may need physical connection like vga
monitor or serial connection to "unlock" the device, very likely I
will hate this security enforcement...  It's just the inconvenience
regardless of whether the said situation should happen.  As a user I'd
like to keep this level of convenience as using password
authentication and turn it off when I see it appropriate.

yousong



Well, we’re at an impasse because some people have said “this should be the new 
norm and it’s a mistake not to disable it unconditionally” and others have said 
the opposite, “yes, okay, let’s do this but only as an option”.

So I’m happy to go other way but we should reach a consensus.

What if it *is* an option but depends on a virtual package that takes a value 
(like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the 
/root/.ssh/authorized_keys file.

Would that work for everyone?

You could still lock yourself out of a box by (a) mis-formatting the keys or 
(b) getting the wrong public keys that don’t match your installed private keys, 
but getting this to be absolutely foolproof is a fool's errand.

So what constitutes “good enough”?

-Philip


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


That would be good for me only if the virtual package fails building and 
blocks the compilation if it does not find the file.


The part I'm worried about is just someone enabling a config option by 
mistake and getting locked out.


-Alberto

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

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Alberto Bursi]

On 02/11/2018 11:54 AM, Yousong Zhou wrote:

On 9 February 2018 at 08:28, Philip Prindeville
 wrote:

From: Philip Prindeville 

Allowing password logins leaves you vulnerable to dictionary
attacks.  We disable password-based authentication, limiting
authentication to keys only which are more secure.

Note: You'll need to pre-populate your image with some initial
keys. To do this:

1. Create the appropriate directory as "mkdir -p files/root/.ssh"
from your top-level directory;
2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
"files/root/.ssh/authorized_keys" and indeed, you can collect
keys from several sources this way by concatenating them;
3. Set the permissions on "authorized_keys" to 644 or 640.


If forgetting doing this means I may need physical connection like vga
monitor or serial connection to "unlock" the device, very likely I
will hate this security enforcement...  It's just the inconvenience
regardless of whether the said situation should happen.  As a user I'd
like to keep this level of convenience as using password
authentication and turn it off when I see it appropriate.

 yousong




This is the risk I also pointed out myself in the github PR about this.

Either this patch adds logic to check if there is indeed the right files 
in /files

and aborts building if not found or you risks locking out yourself.

-Alberto

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

Re: [LEDE-DEV] Bad NAND my sysupgrade / help

[Alberto Bursi]

On 01/31/2018 01:56 PM, Denis Periša wrote:

Hi all,

I got this once before but sent it on RMA.

anyhow, I did some flashing from jffs2 to ubifs and initramfs kernel
image loaded up fine, but on sysupgrade it marked all my kernel
filesystem as bad nand.. 0 space left. I know for sure this is just
fake mark as I copied kernel just before in it and It happended before
to me.

ANY , ANY chance there is some nand tool that can re-check those
blocks and recover it to zero state?

thank you!




I've seen commands in uboot (popular bootloader) that can reset nand bad 
blocks, you would need to connect to serial console by soldering pins to 
the device's board and then using a TTL-USB dongle to connect your PC to it.


But if it keeps doing that it might be a bug in the OpenWrt firmware 
(that can't use the NAND properly and then marks it as bad).


Would be useful to state what is your device.

-Alberto

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

Re: [LEDE-DEV] [OpenWrt-Devel] patchwork

[Alberto Bursi]

On 01/19/2018 01:05 AM, Val Kulkov wrote:

There is more than a handful of PRs currently bit-rotting in
openwrt/packages that are ready for merging, with all requested
changes in place since many months ago. Auto-closing such PRs will
offend the contributors who would see their effort go down the drain
only because no one in the LEDE/OpenWrt community had the time to
review and merge their PRs.


Github has "labels" for PRs, so I think such timeout should look for 
"needs changes" label or something like that.


See this PR https://github.com/openwrt/openwrt/pull/655 (on the right, 
the red label)


-Alberto

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

Re: [LEDE-DEV] Clarify on github lede/openwrt repositories

[Alberto Bursi]

On 18/01/2018 11:21, Mauro Mozzarelli wrote:
Quick question on lede to openwrt remerge (sorry I do not read all the 
messages..)


What is the merged openwrt trunk development repository now?

This?

https://github.com/lede-project/source.git

[so far I have been using this which gets updated]


Or this?

https://github.com/openwrt/openwrt.git

[I found this one following one of today's posts. Do we have to use 
this one from now onwards?]



Are they the same?




OpenWrt repo on Github https://github.com/openwrt/openwrt is the new 
place to send github PRs, and the main git server (for email 
contributors or people contributing to parts not in the Github repo) is 
now https://git.openwrt.org/


OpenWrt git repo was replaced with current LEDE repo after the re-merge, 
so the code is identical.


LEDE github repo will be deactivated or not kept in sync anymore by the 
end of January or something like that, so stop using it.


The old Openwrt github repo (with the pre-merge OpenWrt code) is now 
here https://github.com/openwrt/archive


Also, "trunk" is the old SVN name for what is the "master" branch in as git.

-Alberto


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

Re: [LEDE-DEV] OpenWrt LEDE merge

[Alberto Bursi]

On 16/01/2018 16:11, Andrey Jr. Melnikov wrote:

In gmane.comp.embedded.lede.devel Hauke Mehrtens  wrote:

[...]


Old pre-15.05 OpenWrt CC releases, which are not supported any more, can
be found at https://archive.openwrt.org .

Old https://dev.openwrt.org serving content with untrusted WoSign certificate:

Certificate chain
  0 s:/CN=dev.openwrt.org
i:/C=CN/O=WoSign CA Limited/CN=WoSign CA Free SSL Certificate G2
  1 s:/C=CN/O=WoSign CA Limited/CN=WoSign CA Free SSL Certificate G2
i:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
  2 s:/C=CN/O=WoSign CA Limited/CN=Certification Authority of WoSign
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom 
Certification Authority

Time to move it to Let's Encrypt cert?




Might also be good to think if it's still needed or if it could be just 
shut down.


It's not providing or linking to anything useful now that all 
infrastructure was migrated elsewhere.


-Alberto

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

Re: [LEDE-DEV] [OpenWrt-Devel] owrt landing page

[Alberto Bursi]

Looks ok to me.

-Alberto


On 01/14/2018 06:39 PM, Thomas Endt wrote:

FYI - LEDE wiki styling updated

- Sidebar background added
- Sidebar fontsize increased

--> https://lede-project.org/_media/wiki/ledewiki-owrtstyling2.jpg

Of course, sidebar content to be adapted to OpenWrt i/o LEDE, but apart from 
that: Can we go live with that styling?

Thomas


-Ursprüngliche Nachricht-
Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im Auftrag
von Alberto Bursi
Gesendet: Donnerstag, 11. Januar 2018 19:54
An: lede-dev@lists.infradead.org
Betreff: Re: [LEDE-DEV] [OpenWrt-Devel] owrt landing page

1) sidebar

I think it should have some background to make it readable, and
possible a slight font increase.


2)  logo

see [1] for the thread about the logo. Nothing was decided.

I personally agree that having one of the logos from there would be
great, we'd need to ask the developers/project owners for a vote on
this
as the logo is their own decision to make.

This will probably take months, so for now just use the current logo.

3) my idea was to move in a "legacy" section only the parts the current
LEDE wiki already has (and are the up-to-date ones), while all other
stuff that does not have an equivalent is just added as-is to the
current wiki (just linked in the right place).



1. http://lists.infradead.org/pipermail/lede-dev/2017-May/007783.html

-Alberto


On 01/10/2018 10:56 PM, Thomas Endt wrote:

Hi John,

First results on a private demowiki, see: https://lede-

project.org/_media/wiki/ledewiki-owrtstyling.jpg

1) red marking: What are we going to do with the sidebar (raw,

untouched styling; could be beautified)? Keep or remove?

2) blue marking: I remember there was some discussion about a new,

fresh logo.

 I think now with the move to the LEDE codebase is the right time

to refresh the wiki a bit too.

 Does anybody remember where that discussion happened and what the

outcome was?

3) I changed my mind regarding hard cut. The OpenWrt wiki is still

rw, and we should keep it that way until we have a plan on how to
accomplish the actual merge of the wikis.


Thomas


-Ursprüngliche Nachricht-
Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]

Im

Auftrag von Thomas Endt
Gesendet: Samstag, 6. Januar 2018 18:06
An: 'John Crispin'; 'LEDE Development List'; 'LEDE Project
Administration'; 'OpenWrt Development List'
Betreff: Re: [OpenWrt-Devel] [LEDE-DEV] owrt landing page

Hi John,

Since the styling is based on CSS, we would need the OpenWrt wiki's

CSS

for that. Once we have that, it will be relatively easy.
But instead of doing the merge of the wikis step by step, I would
suggest a hard cut.

1.) Make OpenWrt wiki read only -> I can do that or Imre
2.) Create .tgz of OpenWrt wiki and hand it over to LEDE wiki admins

->

Imre
3.) Move LEDE wiki to OpenWrt styling (apply OpenWrt theme and CSS

to

LEDE
wiki) -> I can do that. Some help of CSS experienced guys could be
necessary for hard cases.
4.) Move content of old OpenWrt wiki to new OpenWrt wiki (former

LEDE)

  -> I can take the toh part (devicepages); dataentries will be

taken

from LEDE since they are way more up to date and contain more
datafields.
  -> Rest of the wiki: A plan needs to be worked out what will be
carried over from old to new OpenWrt wiki -> Community discussion

I'm in the starting blocks since weeks, waiting only for the GO and

the

OpenWrt wiki sources, and I'm sure, we will have some helping heands
ready to start the wiki merge.

Thomas


-Ursprüngliche Nachricht-
Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im

Auftrag

von John Crispin
Gesendet: Freitag, 5. Januar 2018 18:54
An: LEDE Development List; LEDE Project Administration; OpenWrt
Development List
Betreff: [LEDE-DEV] owrt landing page

Hi,

could someone please help us with rebranding the lede landing page

to

an openwrt colour/theme ? i would like to see this swithced over
within the next 7 days.

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] [OpenWrt-Devel] owrt landing page

[Alberto Bursi]

1) sidebar

I think it should have some background to make it readable, and possible 
a slight font increase.



2)  logo

see [1] for the thread about the logo. Nothing was decided.

I personally agree that having one of the logos from there would be 
great, we'd need to ask the developers/project owners for a vote on this 
as the logo is their own decision to make.


This will probably take months, so for now just use the current logo.

3) my idea was to move in a "legacy" section only the parts the current 
LEDE wiki already has (and are the up-to-date ones), while all other 
stuff that does not have an equivalent is just added as-is to the 
current wiki (just linked in the right place).




1. http://lists.infradead.org/pipermail/lede-dev/2017-May/007783.html

-Alberto


On 01/10/2018 10:56 PM, Thomas Endt wrote:

Hi John,

First results on a private demowiki, see: 
https://lede-project.org/_media/wiki/ledewiki-owrtstyling.jpg

1) red marking: What are we going to do with the sidebar (raw, untouched 
styling; could be beautified)? Keep or remove?
2) blue marking: I remember there was some discussion about a new, fresh logo.
I think now with the move to the LEDE codebase is the right time to refresh 
the wiki a bit too.
Does anybody remember where that discussion happened and what the outcome 
was?
3) I changed my mind regarding hard cut. The OpenWrt wiki is still rw, and we 
should keep it that way until we have a plan on how to accomplish the actual 
merge of the wikis.


Thomas


-Ursprüngliche Nachricht-
Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] Im
Auftrag von Thomas Endt
Gesendet: Samstag, 6. Januar 2018 18:06
An: 'John Crispin'; 'LEDE Development List'; 'LEDE Project
Administration'; 'OpenWrt Development List'
Betreff: Re: [OpenWrt-Devel] [LEDE-DEV] owrt landing page

Hi John,

Since the styling is based on CSS, we would need the OpenWrt wiki's CSS
for that. Once we have that, it will be relatively easy.
But instead of doing the merge of the wikis step by step, I would
suggest a hard cut.

1.) Make OpenWrt wiki read only -> I can do that or Imre
2.) Create .tgz of OpenWrt wiki and hand it over to LEDE wiki admins ->
Imre
3.) Move LEDE wiki to OpenWrt styling (apply OpenWrt theme and CSS to
LEDE
wiki) -> I can do that. Some help of CSS experienced guys could be
necessary for hard cases.
4.) Move content of old OpenWrt wiki to new OpenWrt wiki (former LEDE)
 -> I can take the toh part (devicepages); dataentries will be taken
from LEDE since they are way more up to date and contain more
datafields.
 -> Rest of the wiki: A plan needs to be worked out what will be
carried over from old to new OpenWrt wiki -> Community discussion

I'm in the starting blocks since weeks, waiting only for the GO and the
OpenWrt wiki sources, and I'm sure, we will have some helping heands
ready to start the wiki merge.

Thomas


-Ursprüngliche Nachricht-
Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im

Auftrag

von John Crispin
Gesendet: Freitag, 5. Januar 2018 18:54
An: LEDE Development List; LEDE Project Administration; OpenWrt
Development List
Betreff: [LEDE-DEV] owrt landing page

Hi,

could someone please help us with rebranding the lede landing page to
an openwrt colour/theme ? i would like to see this swithced over
within the next 7 days.

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] [PATCH v1] kernel: bump 4.9 to 4.9.75

[Alberto Bursi]

AFAIK AMD processors that don't need that are from Zen onwards. Older 
ones are impacted.


-Alberto


On 08/01/2018 12:27, Nick Lowe wrote:

Hi Kevin,

I am not following :-) For AMD, there should not be a tradeoff as
there is no need for the page table isolation.

Regards,

Nick

On Mon, Jan 8, 2018 at 11:21 AM, Kevin Darbyshire-Bryant
 wrote:



On 8 Jan 2018, at 11:12, Nick Lowe  wrote:

Agreed. So this will seemingly regress something like an APU2 and
therefore probably should not be merged to LEDE as-is?

I’ll let an adult decide the performance/security tradeoff.

___
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/OpenWrt firmware wizard

[Alberto Bursi]

Would providing the text files which are the actual source of the wiki 
pages help making this fully automated?


The source text file is already structured to be parsed by the wiki PHP 
engine that generates the webpage.


This is an example (same page as linked):

= Dataentry =
 dataentry techdata 
Device Type_devicetype : WiFi Router # If 
'other' -> request new devicetype @wiki admin

Brand  : BT # ===> Mandatory  <===
Model  : Home Hub 5 # ===>  
Mandatory  <===
Versions   : Type A # List versions 
comma separated: v1, v1.1, v1.5, v2, v2.5
FCCID_urls :  # link-scheme: 
https://fcc.io/yourFCCid

Availability_availability  : unknown 2017
OWrt Supported Since Rev_hidden    : 
https://dev.openwrt.org/changeset/46223 # 
https://dev.openwrt.org/changeset/x
OWrt Supported Since Rel_hidden    : ¿ # First official 
release (i.e. not trunk)
OWrt Supported Current Rel_hidden  : DD trunk # Current 
official release (i.e. not trunk)
OWrt Unsupported_hidden    :  # e.g. '5GHz wifi'; 
Describe what is not supported


.

OEM Device Homepage URL_url    :  # yourbrand.com/yourdevice
Firmware OEM Stock URL_url :  # 
yourbrand.com/yourdevice/stockfirmware
Firmware OWrt Install URL_hidden   :  # 
downloads.openwrt.org/latest/...factory.bin; If more than 1 file for 
install/upgrade -> link to download *folder* instead of image
Firmware OWrt Upgrade URL_hidden   :  # 
downloads.openwrt.org/latest/...sysupgrade.bin; If more than 1 file for 
install/upgrade -> link to download *folder* instead of image
Firmware LEDE Install URL_url  :  # 
downloads.lede-project.org/releases//targets/...; If more than 
1 file for install/upgrade -> link to download *folder* instead of image
Firmware LEDE Upgrade URL_url  : 
https://downloads.lede-project.org/releases/17.01.4/targets/lantiq/xrx200/lede-17.01.4-lantiq-xrx200-BTHOMEHUBV5A-squashfs-sysupgrade.bin 
# downloads.lede-project.org/releases//targets/...; If more 
than 1 file for install/upgrade -> link to download *folder* instead of 
image





I have a script running weekly in that server to update the package 
lists/tables. It's easy to add a few lines that will make a zip file 
with all these dataentry text files and then place it in the webserver 
folder so you can retrieve it with wget.


I just need to ask tmomas on details (where I can place the zip file so 
it is retrievable from the web) and also if he has any objections (as 
I'm not the server owner/maintainer).


-Alberto

On 01/01/2018 06:09 PM, Moritz Warning wrote:

hi Hauke,

somebody on the forum already pointed me there:

https://forum.lede-project.org/t/firmware-wizard/9039/19
(example was also the same - coincidence? ;-))

That particular site is easy to parse, but most are not (I click random 
entries).
Iirc, I already parsed the TOH table and added image names by hand when it was 
obvious.

On 12/30/2017 02:13 PM, Hauke Mehrtens wrote:


On 11/23/2017 06:44 AM, Moritz Warning wrote:

Hi,

I've put online a firmware wizard for LEDE:

http://mwarning.de/firmware-wizard/
(Sources: https://github.com/freifunk-bielefeld/firmware-wizard)

Build with rather plain HTML5/CSS/JS. Merge requests are welcome.
Everything is still rough around the edges.

It would be nice if downloads.lede-project.org would set 
"Access-Control-Allow-Origin: *",
since the code tries to scrape the download site. So far I use a pre-scraped 
file index as a workaround.
But that causes the file links to not work..

Have fun,
mwarning

Hi Moritz,

I saw your presentation yesterday, but can not find you any more at
34C3. ;-)

Next time try DECT. :-)

You can probably get many meta data from the LEDE wiki which is now more
restructured than the OpenWrt Wiki, see for example this page:
https://lede-project.org/toh/hwdata/bt/bt_homehub_5_type_a

It probably makes more sens to use this as the central storage for board
meta data, using the git has a pretty high entry barrier for external
contributions.

Hauke



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



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

Re: [LEDE-DEV] LEDE Intel Galileo Gen 2 port

[Alberto Bursi]

On 01/01/2018 10:33 AM, p.wa...@gmx.at wrote:

Hi perillamint,

thanks for your effort on getting LEDE run on Galileo.


Recently I got few Galileo Gen 2 boards from Seeed studio clearance. I
tried to boot OpenWRT on them and successfully booted it with some hacks.
(...)
Intel discontinues Galileo and other boards. No one will be able to get
fresh new Galileo boards from Intel.

Galileo itself may be discontinued, but there are other devices based on
Galileo that are not. Here, I'm having a Siemens IOT2040 [1] which is an
"Industrial IoT Gateway". That thing is based on Galileo gen2 and distributors
started shipping a few months ago - so *not* outdated.

The device comes with Yocto Linux, but I'd be much happier seeing it running
LEDE/OpenWrt :-) If you have patches - even in a not-so-clean state - I'd try
them on the IOT2040 here.
Recently, I've checked [2] and made a diff to OpenWrt but have seen, that the
built code is based upon linux 3.18, so the kernel there's quite old. Since
then I have put that project aside. (So many other things to do...)

Looking forward to hearing from you,
Best regards,
P. Wassi

[1]:
https://uk.rs-online.com/web/p/iot-development-kits/1244038/

[2]:
https://github.com/ECG-XMU/OpenWRT-Galileo-gen2


Also Supermicro has a product using Intel Quark SoC like the Galileo 
[1], these things can be found at 250-400$ on ebay, the naked board [2] 
can be found on ebay for 100-200$.


It has 512MB of ECC ram, two 100mbit ports, 2 minipcie, a zigbee module 
slot, a couple USB and a SD card slot, rs 232 and 485 serial ports, so 
it's quite interesting imho.


Does not seem to be discontinued on Supermicro site, and they say it is 
an "embedded long life IoT gateway".


1. https://www.supermicro.com/products/system/Compact/IoT/SYS-E100-8Q.cfm
2. https://www.supermicro.com/products/motherboard/Quark/A1SQN.cfm

-Alberto

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

Re: [LEDE-DEV] x86 comfortable ram for docker image w/ webui

[Alberto Bursi]

On 12/26/2017 09:19 PM, dan wrote:

I'm looking into  using LEDE for providing virtual routers to my
customers (small wISP).  I've used a mikrotik solution in the past,
but that isn't super friendly and hardware support in their more
powerful offerings is missing.

So, I'm looking at using LEDE+LuCI in a virtual configuration.

What is the minimum *comfortable* ram for a home router with
LEDE+LuCI?  This would be on x86, virtualized most likely in docker or
LXC.  The virtualized router would have 1 interface to a bridge on the
host, and one interface to a VLAN on another ethernet port.




I have a testing VM on x86-64 with Virtualbox, with luci installed and 
only default services running.

I gave it 64 MB of RAM (which is the "recommended" amount for devices).

this is the available memory before I start luci
root@LEDE:~# free
             total   used       free shared    
buffers cached

Mem: 55352  20872  34480 72   1900 5276
-/+ buffers/cache:  13696  41656
Swap:    0  0  0

this is the available memory while luci is running
root@LEDE:~# free
             total   used      free shared    
buffers cached

Mem: 55352  22384  32968    132   2020 6320
-/+ buffers/cache:  14044  41308
Swap:    0  0  0

I have used LEDE on real hardware with 32 MB of RAM and while it works 
fine , also luci works fine, they don't have much free memory for 
anything else, even opkg calls to install packages can fail.


On actual devices with 64MB it's all fine, I can do anything I want on 
my router with that.


Since you are running it as a VM you aren't bound to realistic RAM amounts,
you can probably save some space and choose something arbitrary like
45 MB of RAM and it should still be fine for a home router.

-Alberto

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

Re: [LEDE-DEV] new RBM33G board

[Alberto Bursi]

On 12/26/2017 09:35 AM, Outback Dingo wrote:

On Mon, Dec 25, 2017 at 11:39 PM, Daniel Golle  wrote:

Hi Dan,

On Mon, Dec 25, 2017 at 10:50:41AM -0700, dan wrote:

Guys, new product from mikrotik.  RBM33G.  Has a MT7621A CPU w/ 16MB
of flash, 256MB RAM, and pcie m.2.

This thing has 2 mini pci2 slots and 3 gigabit ethernet port and looks
nearly perfect for a dual radio, quad channel mesh box.

Sounds promissing :) And the price is also quite convincing...


I see that there are some devices with this cpu already supported by
lede.  Any chance someone has got their hands on this unit and know if
the bootloader is usable ie if LEDE will run on it?  If not, anyone
take bounties to 'port' LEDE to a specific board?

MT7621 is generally quite straight forward, all boards I've seen for
now use MTK's SDK U-Boot which could even be replaced quite easily
in case it is locked down or anything.
Porting LEDE hence shouldn't be very hard, I estimate that to be one
hack-evening for it to be running somehow, two days to include support
for a non-intrusive initial flash method (support vendors web-ui
firmware format, tftp/recovery or find a backdoor).
I'd be up to do that for getting the hardware + you-name-it.


Cheers


Daniel



the fact that it has only 256mb memory is what makes me not
interested, nice design, lacks memory
probablly a decent enough IoT device for things like home automation
or other, as an AP ? well.



I'm curious. If this device had "enough memory", what you will use it for?
How much is "enough memory" for your use-case?

-Alberto

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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Alberto Bursi]

On 16/11/2017 21:42, Javier Domingo Cansino wrote:

Before this thread falls into oblivion, I would like to ask the guys
on charge of the docs (I think I got the correct emails) for feedback.

The general impression from the list that I have is that there are a
lot of doubts on if such a hardcore change in documentation will work,
but the benefits seem to be understood and good.

What if we kept the ToH + project related webpages as wikis, and we
just moved the guides and howtos to Sphinx based docs? Is this an
alternative you would prefer?

I really just want to improve the docs, so I would appreciate feedback
to either discard this proposal entirely or improve it until it's
accepted.

Cheers,

Javier



Below a summary of all the feedback:

* Alexander raised an idea about having docs and wiki together, I
don't see how we would separate that content, but I'm open to
suggestions.

* Sebastian raised his concerns about deterring casual contributions,
and I think after the text he agreed it's not as good, but is not that
bad neither

* Paul suggesting sticking to the wiki because it's easy to edit. If
possible I would like him to try the flow, as Sebastian did, to see
how more difficult he finds it.

* Alberto raised the concern on editing content by non-developers and
fixing links, however after Sebastian's tests I don't know his
opinion. Supposing of course that I create the appropriate tooling to
check doc correctness. He also suggested other GIT based wiki.

* Jow (for what I could understand) agreed in the idea of having more
control over the content, and that the lack of structure in Wikis make
difficult to find content.
My opinion on this: we are still talking about window dressing. What is 
really needed is that some developer writes and keeps updated core and 
developer documentation, whatever is best for developers to do that is 
good for me.


Since they don't seem terribly interested in documentation in any form 
(only Jow participated in this thread, and didn't say much beyond his 
stylistic preferences and pointing out my mistake), I don't see the 
point in changing the status quo.
It would just shuffle around the same text coming from the OpenWRT wiki 
with minor updates done while it was in LEDE wiki while not changing the 
main issue (and adding his own issues).


I mean OK, with git/readthedocs we would get a versioned documentation, 
but it's not like there is a whole lot of text needing versioning 
anyway, and it's easier to do like it was done in the OpenWRT wiki and 
just state features available since version X or not available anymore 
since version Y.


I'd like to see effort being put into actually creating new 
documentation (reverse-engineering stuff or walking around the code) or 
testing what there is (both on LEDE and OpenWRT).


That said, I'm ok with migrating all the wiki into Sphinx apart from 
project pages and active content like ToH, table of packages and 
device-specific pages (currently only in Openwrt wiki). But I'm still 
just a volunteer maintainer, you'd probably need to talk with Ted Hess 
for the wiki server access (to install Sphynx in it? I don't know how it 
is set up exactly)


-Alberto

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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Alberto Bursi]

On 13/11/2017 13:11, Jo-Philipp Wich wrote:

Hi,


The wiki is working for me. it's great to have the ToH. Also the
device pages are great. However the wiki is not always completely
correct and may be just wrong. It's a wiki, change it! A wiki is
always changing.

I believe that a wiki is no alternative for a proper, curated
documentation. I've also seen many instances where user contributed
information was either incomplete or even factually wrong.


Yeah, but proper documentation (not tutorials, I mean available commands 
and their meaning)
can only be written by developers. So far on the wiki I've seen (even 
large) contributions of mostly user-oriented tutorials.
Someone did add/change the documentation part, (especially after I asked 
for it in the github PRs)
but I have no idea of how correct that is, or how to test it myself on 
my hardware.


This is why I think having developer-grade and core documentation (like 
all uci config files for default system) in git is better, so you can 
enforce contributors to update it with their changes

and check that they aren't writing garbage in it.

While tutorials, ToH, package table/lists and other user-oriented parts 
stay in the wiki.


I don't think forcing the whole wiki into the readthedocs site is a good 
idea just as

leaving all documentation in the wiki is not great.




Another thing I noticed is that some documentation actually seem to have
devolved compared to the OpenWrt wiki. I wrote large parts of
https://wiki.openwrt.org/doc/uci/network - now compare that with
https://lede-project.org/docs/user-guide/network_configuration.

Not even did I struggle to find that page in the first place within the
LEDE wiki, I also couldn't find any trace of the missing ip rule or
route action documentation.

Also TOH != documentation.


~ Jo




I split that page into separate articles under Network Configuration [1] 
to improve its readability.
Same was done for other articles like the dnsmasq one that was split in 
DHCP and DNS articles.
Information in LEDE wiki is arranged by topic, not by what config file 
it is in.
I think the OpenWRT wiki arrangement for that documentation is not 
intuitive for everyone but developers, imho.
(I also converted instructions to use uci commands instead than manual 
text editing with vi, as again
vi isn't terribly user-friendly and mistakes in manual edits can screw 
up the configuration file)


It seems the mentioned part is missing, it's probably a mistake on my 
part, I'm sorry for that.

I'll have a look this evening  to fix it.

1. https://lede-project.org/docs/user-guide/start#basic_configuration

-Alberto

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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Alberto Bursi]

On 11/11/2017 01:40 AM, Javier Domingo Cansino wrote:

Hello,

I have continued working on the docs https://lede.rtfd.io. It now
contains a Proof of Concept, with the following features:

* Documentation can be exported in different formats, html (hosted in
https://lede.rtfd.io), single page html, pdf, ebook etc.
* Documentation has been edited in a single sorted flow, with
references between resources, making it easy to navigate, this works
in pdf, single html, etc, versions too
* It sets the base to have a complete documentation and avoid
duplicates, checking links (sphinx has a linkchecker), and references
within the document

Technical things that still need to be done before replacing the main
wiki with this:

* Port the rest of the content (only the quickstart guide has been
ported). This is a heavy task because of the structural difference
between a wiki and a book.
* Insert Table of Hardware with filter features etc.
* Create a guide on how to contribute to the book

As you can see, I didn't implement some those essential features
because first I would like to see:

* If you like what you see
* if you have any needs apart from what I did and stated is needed
* A decision to proceed with a roadmap and help if possible

I don't have clear what process needs to be followed for the
decision/roadmap, so I leave that up to you, and will reply with
ideas.

Cheers,

Javier




Well, I like readthedocs, but I still think it is too simplistic for our 
needs. The issues I raised are still there.


Editing the page happens through Github's web editor and web interface, 
both are utter garbage for code, and even more so for text-based 
documentation. Plus the whole fact that you are required to open a PR, 
which is a completely alien concept for non-developers.


Second thing is that internal links to other pages should adjust 
themselves automatically. This is really a big thing, as I'm not a fan 
of going and fixing dozens of links manually every time I or some newbie 
moves/changes something.


So basically still some kind of wiki system for the frontend, but with 
git-based versioning.


Have you looked at git-based wikis? because there is no way around it, 
we still need a wiki-like system (yes, even Github's own wiki is better 
than its web code editor)

https://www.perforce.com/blog/comparison-of-git-powered-wikis-in-cloud-based-scm-tools
I don't know if the internal link thing is handled by all the wikis in 
the following list, but they at least all allow wiki-like internal links.


-Alberto

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

Re: [LEDE-DEV] 17.01.4 on Mikrotik RB951Ui-2HnD

[Alberto Bursi]

On 03/11/2017 11:22, Nishant Sharma wrote:

Hi Alberto,

On Friday 03 November 2017 01:44 PM, Alberto Bursi wrote:



On 03/11/2017 08:04, Nishant Sharma wrote:


I am not able to find the documentation to install Lede 17.01.x on 
RB951Ui-2HnD.




The device has since then gone into a boot loop. I searched on the 
forum as well, but couldn't find a solution.


I've seen a thread in the forum too, (with no answer) so if you 
confirm it works either post there or report back here and I'll post 
the same instructions there too.
https://forum.lede-project.org/t/installing-on-mikrotik-rb951ui-2hnd/3751 



Thanks for your reply. I will put them on the forum as well.

Here are the steps:

1. Download vmlinux-initramfs.elf 
(lede-17.01.4-ar71xx-mikrotik-vmlinux-initramfs.elf) and use it as 
boot file.
2. DHCP didn't give IP Address. Had to ssh using IPv6 address. Or 
statically assigning an IP of 192.168.1.x to my machine.
3. scp lede-17.01.4-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin 
to the router.
4. sysupgrade -n 
lede-17.01.4-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin

5. Router reboots after upgrade

Where did my 20 MB of flash space go?

df -h with old firmware:
Filesystem    Size  Used Available Use% Mounted on
rootfs  124.0M 35.4M 88.6M  29% /
/dev/root   124.0M 35.4M 88.6M  29% /
tmpfs    61.8M 61.8M 0 100% /tmp
tmpfs   512.0K 0    512.0K   0% /dev

df -h with new firmware:
Filesystem    Size  Used Available Use% Mounted on
/dev/root 2.5M  2.5M 0 100% /rom
tmpfs    61.2M 52.0K 61.1M   0% /tmp
/dev/ubi0_2 103.0M 36.0K 98.3M   0% /overlay
overlayfs:/overlay  103.0M 36.0K 98.3M   0% /
tmpfs   512.0K 0    512.0K   0% /dev

Regards,
Nishant



They adjusted partitions (which is why you couldn't just sysupgrade from 
OpenWRT).
Actually, with the new firmware you have 10 MB more usable space, even 
if partition is smaller.

Look at the "Available" column. Old fw was 88MB, new fw is 98MB.

-Alberto

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

Re: [LEDE-DEV] 17.01.4 on Mikrotik RB951Ui-2HnD

[Alberto Bursi]

On 03/11/2017 08:04, Nishant Sharma wrote:

Hi,

I am not able to find the documentation to install Lede 17.01.x on 
RB951Ui-2HnD.


I used to install OpenWrt 15.05 using TFTP boot, mtd erase and 
unpacking the tar.gz of the rootfs to mtdblock2 and copying the kernel 
to mtdblock1.


But with Lede 17.01.4, there is no tar.gz. I tried doing:

mtd write rootfs.squashfs rootfs

and copy the kernel to mtdblock1

The device has since then gone into a boot loop. I searched on the 
forum as well, but couldn't find a solution.


Any pointers for the same would be helpful.

Thanks in advance.

Regards,
Nishant

___



That target has the "ramdisk" feature enabled by default, so one of the 
files generated by a default compile can be sent over tftp, and then 
booted from RAM
The system may lack Luci but will have SSH and after connecting to it 
you can do a sysupgrade through the commandline, which will write the 
firmware on flash.


Try the ones with "initramfs" in the name, I suspect the right one is 
the "vmlinux-initramfs.bin" or the .elf.


I've seen a thread in the forum too, (with no answer) so if you confirm 
it works either post there or report back here and I'll post the same 
instructions there too.

https://forum.lede-project.org/t/installing-on-mikrotik-rb951ui-2hnd/3751

-Alberto


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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Alberto Bursi]

On 27/10/2017 15:14, Javier Domingo Cansino wrote:

And yes, I'm talking of things I can/will do personally.

Is there any way to access all the wiki files? I am doing it manually
and its turning out to be quite tedious... =)



afaik the only way is accessing the server itself over ssh. There all 
wiki pages are stored as plaintext (not as html).


-Alberto

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

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Alberto Bursi]

On 10/23/2017 09:43 PM, Emmanuel Grumbach wrote:

On Mon, Oct 23, 2017 at 9:50 PM, Emmanuel Grumbach  wrote:

On Mon, Oct 23, 2017 at 8:30 PM, Baptiste Jonglez
 wrote:

Hi,

On 23-10-17, Emmanuel Grumbach wrote:

I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
haven't found any image in
https://lede-project.org/toh/views/toh_fwdownload that claims it
features that version. I can see v1 and v2, but not v4.

Support for this board has just been merged: 
https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463

So, there is no support in 17.01 but snapshot images should work, and the
ToH at actually links to downloadable images :)

   https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v


Hmm... Broken link.
I took v4 at the end, but I couldn't get the webUI. The device did
respond to SSH though.
I tried to sysupgrade back to the stock firmware, but I screwed it up
apparently.
Now it doesn't even boot. Leds blink a bit and shut down immediately.

Seems like it is a brick now :(




Snapshot images don't have webUI, you need to install it from ssh (so 
that part was normal).
Snapshot images also have other limitations (you can't install 
driver-related packages after a few days and you need to do a full 
upgrade first, or use the Image Builder to integrate all packages in the 
firmware, see the wiki 
https://lede-project.org/docs/user-guide/imagebuilder )


That said, most modern routers have a bootloader with a recovery mode 
you can use to send over another firmware image for it to reflash. If 
you did not hose the first blocks of the onboard flash, the bootloader 
is still alive and you should be able to recover the router without 
factory flashing tools.


The v2 version of that router seems to have it (should be the same or at 
least very similar to yours, imho), see here 
https://mikepalmer.net/tp-link-archer-c7-ac1750-v2-tftp-recovery/
or google around for similar instructions for your device. (the "Make 
the router think its getting a normal recovery firmware" part is 
renaming the openwrt factory flash firmware into the name the recovery 
is looking for)


If you don't know how to set up a tftp server, see the wiki here 
https://lede-project.org/docs/user-guide/tftpserver


-Alberto

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

Re: [LEDE-DEV] Linksys WRT54GL / image builder

[Alberto Bursi]

On 10/20/2017 02:54 PM, Mikael Bak wrote:

Hi Jo,

On 20/10/17 10:59, Jo-Philipp Wich wrote:

Hi Mikael,

try "make info", that should display the required package set per 
device.




Thanks for the info.

$ make info
[snip]
linksys-wrt54g:
    Linksys WRT54G
    Packages: kmod-b43 kmod-b43legacy
[snip]

So I did this:
$ make image PROFILE=linksys-wrt54g PACKAGES="kmod-b43 kmod-b43legacy"

And it got me a quite small, basic image without luci that fit on my 
device.


FYI: the image I can download from today's snapshot is too big to fit 
on these devices (3.7MB). The image I built is only 3.5MB.
So I'm asking how is the package list determined for a device when the 
snapshots are built?


Is there a make command in the image builder I can run to see what the 
default packages are for a given device?


Thanks again,
Mikael

If you launch a image build without any PACKAGES= set you will see what 
are the default packages in the first lines of the output, see the 
following example:


$ make image PROFILE="wt3020-8M"

Building images for ramips - Nexx WT3020 (8MB)
Packages: base-files busybox dnsmasq dropbear firewall fstools ip6tables 
iptables kernel kmod-gpio-button-hotplug kmod-leds-gpio kmod-mt76 
kmod-rt2800-pci kmod-rt2800-soc libc libgcc logd mtd netifd odhcp6c 
odhcpd opkg ppp ppp-mod-pppoe swconfig uci uclient-fetch wpad-mini


[and then it starts downloading packages]

-Alberto

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

Re: [LEDE-DEV] [RFC] adding CPE IDs to package Makefiles

[Alberto Bursi]

On 10/01/2017 02:43 PM, Jo-Philipp Wich wrote:

Hi,

I'd like to propose adding structured CPE information to package
Makefiles in order to simplify mapping of discovered vulnerabilities to
affected LEDE software components.




I like this. I know of OPNSense (firewall distro based off BSD I think)
that does something like this, it has a button in its web gui to show
this information.

-Alberto

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

[LEDE-DEV] kmodloader-related kernel crash

[Alberto Bursi]

On the lede forum there is a user that posted a serial boot log where it 
seems kmodloader is causing a kernel oops while loading the wifi driver 
on a Huawei HG655 (previously supported and working fine in OWrt Chaos 
Calmer).

https://forum.lede-project.org/t/something-wrong-in-firmware-on-hg655b/3602/7

ccing to Hans Dedecker as he seems to be interested in kmodloader at the 
moment.

-Alberto

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

[LEDE-DEV] [RFC] creating LEDE GPT image using raw GPT partition dump

[Alberto Bursi]

I'm trying to add support for a nas box whose stock "firmware" was 
actually installed in the sata hard drive. Iomega EZ, which is a lower 
end version of Iomega ix2-nd that also has this feature, there are 
others like some single drives from Lacie, I think.

Therefore, it needs to be GPT.

Stock is using GPT too but it's kind of irrelevant for the bootloader as 
the stock kernel/firmware are flashed raw in the first 100MB of 
unallocated space anyway (and both run from RAM, apparently).

By looking around, it seems the LEDE buildsystem is unable to create GPT 
images, it lacks gdisk tool, and I don't even know if it supports using 
loop devices (to use gdisk to make the partition table inside the disk 
image).

Since I don't know enough C to add GPT to the current binary tool used 
to make the mbr for the images, I am experimenting with dumping the main 
GPT partition table (first 2-ish MB) from a drive formatted like the 
target image, then assemble the image with dd like is done for sdcard or 
x86 images.

This would require the resulting LEDE image to do some fixup at first 
boot (like recreating the backup GPT partition table at the end of the 
drive) which would be required anyway to adjust GPT to the actual size 
of the target disk.

That's not a major issue as there is Gdisk package already in package 
repo (I would need to import it in LEDE), and space in these devices 
isn't an issue.

What I ask is if something like this is acceptable for LEDE, as I'm 
using a small (around 500 Bytes when xz-compressed) raw GPT table dump 
in this process.

-Alberto

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

Re: [LEDE-DEV] github oauth for webpage editing requests too many permission

[Alberto Bursi]

On 06/08/2017 02:44 PM, Thomas Endt wrote:
> Seems there is finally some movement after I nudged a bit: Pull request has
> been opened.
> https://github.com/cosmocode/dokuwiki-plugin-oauth/issues/41
>
> However, the real implementation date is still unknown, and since the
> solution is so easy, I'd say: Go ahead, apply that change to the LEDE wiki.
>
>
> Thomas
>
>
>

I fixed it and tested with my github account, it asks only for read-only 
access to email now.

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

Re: [LEDE-DEV] github oauth for webpage editing requests too many permission

[Alberto Bursi]

On 06/07/2017 05:45 PM, Martin Tippmann wrote:
> On Wed, Jun 7, 2017 at 5:00 PM, Karl Palsson  wrote:
>> Hi,
>>
>> I was trying to fix something on the documentation pages of
>> lede-project today, and tried to login with github.
>>
>> However, the docuwiki/oauth thing is demanding full read/write
>> access to my account, which seems excessive...
> Hi, we already noticed this:
> http://lists.infradead.org/pipermail/lede-dev/2016-October/003099.html
>
> https://github.com/cosmocode/dokuwiki-plugin-oauth/issues/41
>
> Looks like the original plugin is still not updated.
>

Seems like the fix is pretty trivial though (change a line in a php 
file), see this commit from a fork:
https://github.com/micgro42/dokuwiki-plugin-oauth/commit/39b9184bb4c606c3d0fc43d8e565368bcaab2f92

Anyone with root access to the server can easily do that on our side.

I can do that if we agree it's OK to do so.

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

Re: [LEDE-DEV] Archer c7 corrupted firmware bootloop - tftp aborting - serial not working

[Alberto Bursi]

On 06/04/2017 02:54 PM, QWeRKUS qwErkus wrote:
> Thank you for your reply. JTAG seems even trickier than serial. So far
> all my attempts to scan for a valid JTAG chain end up with:
>
> Error: JTAG scan chain interrogation failed: all zeroes
>
> There a just too many variables to check for a newbie like myself, so
> I guess I'll go with the spi programmer. Turns out this is another
> thing the pi can do (via flashrom) so no need for new hardware. Are
> you sure you need to desolder the chip though ? Shouldn't this be
> working with a 8 pin SOIC clamp and and external 3.3V power source (I
> have an old ATX PSU doing the job) ?
>
>
It should, but in some cases it does not (depends from how the board was 
designed) and in those situations you need to desolder the chip. I got 
most of these "cases where it does not work" in PC and laptop boards though.

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

Re: [LEDE-DEV] mt7621 Persistent FS issue with 4.9 kernel

[Alberto Bursi]

On 05/23/2017 12:10 PM, K.Mani wrote:
> Mediatek board 'mt7621' boots successfully on LEDE 4.9 kernel with
> 'mt7621-initramfs-kernel.bin'.
> But when I flash 'squashfs-sysupgrade.bin' to get persistence storage
> the image crashes leading to reboot.
> Both the images are flashed from u-boot prompt.
>
I thought the procedure was to boot the initramfs image, then you do a 
normal sysupgrade while you are still booted in the initramfs image.

Why are you flashing the sysupgrade image from uboot?

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

Re: [LEDE-DEV] convention on uid/gid for packages

[Alberto Bursi]

On 05/15/2017 07:29 PM, Tobias Welz wrote:
>
> If not, there would be the need to do some post-processing after 
> restore to somehow fix gids/uids to make everything work again; but it 
> will be an extra level of complexity. 

uhm, I might say something very noobish, but...

are all packages groups/uids added  to /etc/passwd which is a static 
text file?

Would it make sense to backup/restore it on sysupgrade (if it isn't 
already in the whitelist)?

That way services get random uids but they are preserved across 
sysupgrades in a very easy way.

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

[Alberto Bursi]

On 05/12/2017 09:48 PM, Stefan Peter wrote:
>
>  From the comments on this thread, I get the impression the quite some
> non-committing members of the community feel the same: The didn't even
> get asked about their opinion regarding the naming or the structure of
> the organisation that will result from the merge. And we all have our
> opinions, and some of us need to sell the results of the committing
> developers to their management. Shouldn't we as users and supporters and
> whatnot get the chance to be heard, at least?
>
>

Well, it's not like they are removing people's ability to voice their 
opinions here.

It is unrealistic, dangerous and quite unfair to give any kind of 
decision-making power to normal users.

I mean, it's not fair to have users take decisions that will then bind 
the ones actually working in their spare time.

People actually carrying the weight of the project get to decide where 
it goes. It's *their* project, not ours.

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

[Alberto Bursi]

On 05/12/2017 10:02 AM, 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.
>
>

For what is worth, I agree with what Edwin wrote here.

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

[Alberto Bursi]

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.

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

Re: [LEDE-DEV] Asterisk Update

[Alberto Bursi]

On 04/29/2017 12:52 PM, jalb-led...@freenet.de wrote:
> Please update Asterisk to the newest version.
>
>
> Mit freenetmail sicher kommunizieren!
> [https://email.freenet.de/emig/index.html?utm_medium=Text_source=Footersatz_campaign=Footersatz_Sicherheit170207=e990699_content=Text]
> Wir garantieren Ihnen verschlüsselte Datenübertragung &
> Datenspeicherung auf deutschen Servern - E-Mail made in Germany!
>

Asterisk is in this github package feed repository 
https://github.com/openwrt/telephony , send your patches there by 
opening a PR.

-Alberto

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

Re: [LEDE-DEV] [PATCH] asterisk-13.x: Add func_periodic_hook module

[Alberto Bursi]

On 04/24/2017 09:43 AM, John Crispin wrote:
>
>
> On 20/04/17 15:37, Roman Spychała wrote:
>> From: Roman Spychała 
>>
>> Signed-off-by: Roman Spychała 
>> ---
>>   net/asterisk-13.x/Makefile | 1 +
>>   1 file changed, 1 insertion(+)
>
> Hi Roman,
>
> asterisk is part of the packaged feed on github. please send the patch 
> as a PR there.
>
> John
>
>

Telephony feed, this is the github https://github.com/openwrt/telephony

-Alberto

>>
>> diff --git a/net/asterisk-13.x/Makefile b/net/asterisk-13.x/Makefile
>> index b2d1275..0722098 100644
>> --- a/net/asterisk-13.x/Makefile
>> +++ b/net/asterisk-13.x/Makefile
>> @@ -380,6 +380,7 @@ $(eval $(call 
>> BuildAsterisk13Module,func-global,Global variable,global variable
>>   $(eval $(call BuildAsterisk13Module,func-groupcount,Group count,for 
>> counting number of channels in the specified group,,,func_groupcount,,))
>>   $(eval $(call BuildAsterisk13Module,func-math,Math functions,Math 
>> functions,,,func_math,))
>>   $(eval $(call BuildAsterisk13Module,func-module,Simple module check 
>> function,Simple module check function,,,func_module,))
>> +$(eval $(call BuildAsterisk13Module,func-periodic-hook,Periodic 
>> dialplan hooks,Execute a periodic dialplan hook into the audio of a 
>> call,,,func_periodic_hook,,))
>>   $(eval $(call BuildAsterisk13Module,func-presencestate,Hinted 
>> presence state,Gets or sets a presence state in the 
>> dialplan,,,func_presencestate,,))
>>   $(eval $(call BuildAsterisk13Module,func-realtime,realtime,the 
>> realtime dialplan function,,,func_realtime,,))
>>   $(eval $(call BuildAsterisk13Module,func-shell,Shell,support for 
>> shell execution,,,func_shell,,))
>
>
> ___
> 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] Proper way to deal with "dual firmware" ar71xx devices

[Alberto Bursi]

On 04/23/2017 08:40 PM, Bjørn Mork wrote:
> Hello,
>
> Many devices make use of "dual firmware" configurations, splitting the
> available flash and allowing two complete and independent installations.
> This works fine for devices like the Linksys WRT1900AC etc, where the
> boot loader make sure the kernel command line "root=" parameter matches
> the booted kernel.
>
> It does not work so well with ar71xx devices like the Ubiquiti UniFi AC
> Pro. The original firmware use this layout:
>
> dev:size   erasesize  name
> mtd0: 0006 0001 "u-boot"
> mtd1: 0001 0001 "u-boot-env"
> mtd2: 0079 0001 "kernel0"
> mtd3: 0079 0001 "kernel1"
> mtd4: 0002 0001 "bs"
> mtd5: 0004 0001 "cfg"
> mtd6: 0001 0001 "EEPROM"
>
>
> The current LEDE images configure this as:
>MTDPARTS = 
> spi0.0:384k(u-boot)ro,64k(u-boot-env)ro,7744k(firmware),7744k(ubnt-airos)ro,128k(bs)ro,256k(cfg)ro,64k(EEPROM)ro
>
>
> Note that "kernel0" is statically mapped to "firmware", and that
> "kernel1" (or "ubnt-airos") is made read-only.  This sort of works as
> long as LEDE is installed on "kernel0". But LEDE/OpenWrt does its magic
> partition splitting based of the "firmware" partifion name.  And it will
> do this even if the currently booting LEDE kernel is located on
> "ubnt-airos"/"kernel1".
>
> Due to limited understanding of how the Ubiquiti U-Boot selects between
> "kernel0" and "kernel1", there are instructions out there telling users
> to try to install LEDE on both "kernel0" and "kernel1".  But what
> happens if the boot loader is actually loading the "kernel1" image? We
> will then have a system with the kernel loaded from "kernel1" but the
> rootfs loaded from "kernel0".  This is bad.  When sysupgrading, the
> image on "kernel0" (aka "firmare") is replaced, But the boot loader will
> still continue to load the old LEDE kernel from "kernel1".  If you are
> lucky, it will boot successfully using the new rootfs.  You can then use
> the mtd-rw package to make "ubnt-airos" writeable and copy the new
> kernel there.  Extremely confusing and unfriendly to users...
>
> This should be fixed somehow.  But I don't know how.  The best would be
> to make the kernel dynamically figure out which of the partitions it
> booted from and then force the rootfs there.  But I don't know if this
> can be done without the help of the boot loader?
>
> Another option would be to make two different systems, where the command
> line for the "kernel1" installation switched the order of the "firmware"
> and "ubnt-airos" partitions.  But this would require the user to select
> the correct image on installation. Not exactly user friendy...
>
> Any better ideas or advice is appreciated.
>
> Until this problem is resolved, I believe all installation instructions
> for such devices should emphasize that LEDE/OpenWrt *must* be installed
> on "kernel0" only!
>
> Note that the boot loader appears to select "kernel0" or "kernel1" based
> on the first bit of the "bs" partition.  This partition contains two
> 32bit numbers, where the first one is 0x8000 if "kernel1" is booted
> and 0x if  "kernel0".  The second number appears to be a magic,
> and is always 0xa34de82b (both numbers given as big endian here).  The
> rest of the partition are zeroes.
>
>
>
>
> Bjørn
>
>

Can this  "bs" partition be manipulated on installation or later? If it 
can be manipulated it's not that hard to just erase the flash with the 
first 32bit number so it is 0x00 or maybe add a check in sysupgrade 
procedure that reads that and automatically erases the cells if it finds 
them not at 0x00 already.

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

Re: [LEDE-DEV] MT7621 support Jumbo frames

[Alberto Bursi]

Weird, I'm not seeing the whole "mediatek" folder if I try to follow 
your steps from a fresh source download with LEDE master (trunk/HEAD, 
whatever).

I've checked the LEDE 17.01 branch and yes, there the "mediatek" folder 
is there and also that file. Kernel version is the same for both, 
4.4.61, and that "mediatek" folder isn't there in the source package 
downloaded so it must come from LEDE patches.

So go in main source folder and write "git checkout lede-17.01" then it 
should work.

-Alberto


On 04/23/2017 12:52 PM, Jaap Buurman wrote:
> Thank you all for the suggestions. I've tried the following steps:
>
> 1) Add the patch in a file with a name so that it will be added last:
> 999-mtu.patch. This failed during the build.
> 2) Next, I wanted to write these changes manually to a patch with
> quilt. However, the file /drivers/net/ethernet/mediatek/gsw_mt7620.h
> was not there, so I could not apply those changes manually either.
> That was the only file that gave me issues. The other files could be
> found in the build_dir, and thus I could apply all the changes
> manually. So that's where I'm stuck at the moment.
>
> On Sun, Apr 23, 2017 at 11:34 AM, Alberto Bursi
> <alberto.bu...@outlook.it> wrote:
>> That patch is a raw kernel patch, you need to integrate it in LEDE's
>> buildsystem and hope that he is working with LEDE patches already applied.
>>
>> Copy the patch's text in a text file and place this file in the /patches-*
>> folder in your device's source folder
>>
>> Your SoC is a ramips so it should be target/linux/ramips/patches-4.4 as he
>> said it is for kernel 4.4.7
>>
>> Give it a name that makes sure it will be added last, like 999-mypatch.patch
>>
>> Then you can select your device with make menuconfig and then start a
>> compilation with make and see if it goes well.
>>
>> If that fails, you need to follow the tutorial as linked, and create a new
>> kernel patch where you write these changes manually to each file he changed,
>> then save the new patch, and then move the patch file you created from the
>> quilt kernel patch folder (platform/) to the patch folder as said above.
>>
>> There might be better ways, but that's what I did when I had to add new
>> kernel patches.
>>
>> -Alberto
>>
>>
>> On 04/22/2017 01:53 PM, Jaap Buurman wrote:
>>
>> I have never applied patches before, so I am probably making mistakes.
>> The first problem I'm running into, is that it is trying to patch the
>> following file:
>>
>> /drivers/net/ethernet/mediatek/gsw_mt7620.h
>>
>> However, such a file does not exist in that path in my build_dir. I
>> can find gsw_mt7620.c and gsw_mt7620.o files just fine in the
>> aforementioned path, but not the .h file it is trying to patch. To
>> which branch does the patch apply cleanly? I am currently trying to
>> patch the master branch. Should I try the 17.01 branch instead?
>>
>> On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman <jaapbuur...@gmail.com>
>> wrote:
>>
>> Ah, that sounds even better :) I will try to compile and test this
>> patch tomorrow or the day after tomorrow. Will let you know if it
>> works. Thanks again for the effort you're putting into this!
>>
>> On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli
>> <gaetano.cata...@gmail.com> wrote:
>>
>> I'm still working on this since I would like to raise the limit up to
>> 9KB if possible. Please, let me know if this works for you.
>>
>> On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman <jaapbuur...@gmail.com>
>> wrote:
>>
>> Wow, this is perfect. Thank you very much. I will try to use this
>> patch and compile my own image with up to 2kb frame support. Do you
>> have any plans on submitting this as a PR to the LEDE git?
>>
>> On Wed, Apr 19, 2017 at 9:32 AM, Gaetano Catalli
>> <gaetano.cata...@gmail.com> wrote:
>>
>> I've been working on this for a while. Apparently the embedded 5-port
>> gigabit switch is able to handle packets with size up to 15KB. On the
>> contrary, the GMAC, to which the switch is attached, has a limit of
>> 2KB. The following is a patch that changes the max recv frame length
>> to 2KB and allows to set the MTU up to that value. It is based on
>> kernel 4.4.7.
>>
>> Signed-off-by: Gaetano Catalli <gaetano.cata...@gmail.com>
>> ---
>>   drivers/net/ethernet/mediatek/gsw_mt7620.h  |  6 +
>>   drivers/net/ethernet/mediatek/gsw_mt7621.c  | 13 +++
>>   drivers/net/ethernet/mediatek/mtk_eth_soc.c | 36
>> ++-

[LEDE-DEV] MT7621 support Jumbo frames

[Alberto Bursi]

(resent to the list because my client decided to use HTML for some reason)

That patch is a raw kernel patch, you need to integrate it in LEDE's 
buildsystem and hope that he is working with LEDE patches already applied.

Copy the patch's text in a text file and place this file in the 
/patches-* folder in your device's source folder

Your SoC is a ramips so it should be target/linux/ramips/patches-4.4 as 
he said it is for kernel 4.4.7

Give it a name that makes sure it will be added last, like 999-mypatch.patch

Then you can select your device with make menuconfig and then start a 
compilation with make and see if it goes well.

If that fails, you need to follow the tutorial as linked, and create a 
new kernel patch where you write these changes manually to each file he 
changed, then save the new patch, and then move the patch file you 
created from the quilt kernel patch folder (|platform/)| to the patch 
folder as said above.

There might be better ways, but that's what I did when I had to add new 
kernel patches.

-Alberto


On 04/22/2017 01:53 PM, Jaap Buurman wrote:
> I have never applied patches before, so I am probably making mistakes.
> The first problem I'm running into, is that it is trying to patch the
> following file:
>
> /drivers/net/ethernet/mediatek/gsw_mt7620.h
>
> However, such a file does not exist in that path in my build_dir. I
> can find gsw_mt7620.c and gsw_mt7620.o files just fine in the
> aforementioned path, but not the .h file it is trying to patch. To
> which branch does the patch apply cleanly? I am currently trying to
> patch the master branch. Should I try the 17.01 branch instead?
>
> On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman  wrote:
>> Ah, that sounds even better :) I will try to compile and test this
>> patch tomorrow or the day after tomorrow. Will let you know if it
>> works. Thanks again for the effort you're putting into this!
>>
>> On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli
>>   wrote:
>>> I'm still working on this since I would like to raise the limit up to
>>> 9KB if possible. Please, let me know if this works for you.
>>>
>>> On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman  
>>> wrote:
 Wow, this is perfect. Thank you very much. I will try to use this
 patch and compile my own image with up to 2kb frame support. Do you
 have any plans on submitting this as a PR to the LEDE git?

 On Wed, Apr 19, 2017 at 9:32 AM, Gaetano Catalli
   wrote:
> I've been working on this for a while. Apparently the embedded 5-port
> gigabit switch is able to handle packets with size up to 15KB. On the
> contrary, the GMAC, to which the switch is attached, has a limit of
> 2KB. The following is a patch that changes the max recv frame length
> to 2KB and allows to set the MTU up to that value. It is based on
> kernel 4.4.7.
>
> Signed-off-by: Gaetano Catalli
> ---
>   drivers/net/ethernet/mediatek/gsw_mt7620.h  |  6 +
>   drivers/net/ethernet/mediatek/gsw_mt7621.c  | 13 +++
>   drivers/net/ethernet/mediatek/mtk_eth_soc.c | 36 
> ++---
>   drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
>   drivers/net/ethernet/mediatek/soc_mt7621.c  |  2 +-
>   5 files changed, 39 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/gsw_mt7620.h
> b/drivers/net/ethernet/mediatek/gsw_mt7620.h
> index dcef9a8..ce3cd10 100644
> --- a/drivers/net/ethernet/mediatek/gsw_mt7620.h
> +++ b/drivers/net/ethernet/mediatek/gsw_mt7620.h
> @@ -45,6 +45,12 @@
>   #define GSW_REG_ISR 0x700c
>   #define GSW_REG_GPC1 0x7014
>
> +#define GSW_REG_MAC_P0_MCR 0x100
> +#define GSW_REG_MAC_P1_MCR 0x200
> +
> +// Global MAC control register
> +#define GSW_REG_GMACCR 0x30E0
> +
>   #define SYSC_REG_CHIP_REV_ID 0x0c
>   #define SYSC_REG_CFG1 0x14
>   #define RST_CTRL_MCM BIT(2)
> diff --git a/drivers/net/ethernet/mediatek/gsw_mt7621.c
> b/drivers/net/ethernet/mediatek/gsw_mt7621.c
> index 96280b4..db5d56d 100644
> --- a/drivers/net/ethernet/mediatek/gsw_mt7621.c
> +++ b/drivers/net/ethernet/mediatek/gsw_mt7621.c
> @@ -99,17 +99,20 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw,
> struct device_node *np)
>usleep_range(10, 20);
>
>if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0x) == 0x0101) {
> - /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
> - mtk_switch_w32(gsw, 0x2105e30b, 0x100);
> + /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 2k) */
> + mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR);
>mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
>} else {
> - /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
> - mtk_switch_w32(gsw, 0x2105e33b, 0x100);
> + /* (GE1, Force 

Re: [LEDE-DEV] Planning v17.01.1

[Alberto Bursi]

On 04/09/2017 04:14 PM, Jo-Philipp Wich wrote:
> Hi,
>
> I'd like to start preparing the v17.01.1 release during the upcoming
> week with the goal to release final binaries during the easter holidays
> (~14.04. - 17.04.).
>
> You can find the current list of changes since v17.01.0 at
> https://lede-project.org/releases/17.01/changelog-17.01.1
>
> If you want specific fixes cherry-picked/backported to lede-17.01,
> please mention them in a reply to this mail.
>
> If you have any objections to the release time frame, please speak up :)
>
>
> Also, please reply with a quick ACK / NACK on whether you'd like to see
> an -RC build before 17.01.1 final.
>
>
> Thanks,
> Jo
>
>

I'm probably late, but I'd like to ask for f2fs-tools to be updated as 
the newer version in snapshot fixes a bad issue where fsck.f2fs hoses a 
f2fs partition instead of fixing it, see here for details 
https://github.com/lede-project/source/pull/958

-Alberto


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

Re: [LEDE-DEV] [PATCH v2] ar71xx: Add TP-LINK TL-WR841N v12 support.

[Alberto Bursi]

On 03/30/2017 06:21 AM, Vittorio G (VittGam) wrote:
>
> Thanks for your suggestion. I knew the exact contrary and in fact I'm
> adding dot at end of subject every time... Do you know if there is some
> place (that I might have very well missed if it exists...) where this
> kind of style rules are written?
>
>

See this page in the site/wiki https://lede-project.org/submitting-patches

-Alberto

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

Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency

[Alberto Bursi]

On 03/29/2017 05:39 PM, James Feeney wrote:
> Hi Alberto
>
>> Also the kernel is handled like a package for the build system, but
>> since most devices expect it outside of root filesystem in various ways,
>> it's added to the firmware image the way the device's bootloader expects it.
> I haven't seen a preferred term for the class of this combined.  LEDE does 
> name each of them individually, based upon the target
> architecture.  It would be nice to have some generally recognized single name
> for this class, "the kernel-fs packages" or some such.
>
> Of course it's a little complicated, since most traditional Linux distros 
> target
> only one or two hardware architectures, and LEDE targets many many different
> target architectures.  But then, that's the whole point of LEDE.
>

I've seen it called "image", as it is basically a disk image ready to be 
flashed on raw flash (for most devices), or simply "firmware" as the end 
result is a complete and bootable firmware if installed correctly.

> So, if I understand, there always exists a set of hashes to verify that, at 
> any
> time in the future, a package can be built which is identical to any package
> built in the past.

The hash is to verify integrity of source package downloaded from 
upstream, afaik there is a hash after compilation, but that is generated 
automatically and listed in the package lists read by opkg only. It's 
not stored permanently.

You can revert to an older version of LEDE git and compile the same 
package with its build system, assuming you still have access to the 
same source package or git repo or whatever that was used before.

> Bastian also mentions "checkout LEDE and all feeds at a specific timestamp" as
> an approach.  This suggest two general tracking mechanisms: 1) tracking by 
> hash,
> and 2) tracking by time-stamp.  Is one of these mechanisms, or are both of 
> these
> mechanisms, used universally in the LEDE package management system?

I think he meant that they are doing like that to make their own 
downstream LEDE-based firmwares. They tag a timestamp in LEDE snapshot 
or whatever, and stick to it until they decide to tag the next.

In any case LEDE is either downloading a source archive from a specific 
release version (and using the hash) or fetching source from a specific 
commit in a versioning system like git or subversion or whatever.

>
> Hmm - it is not entirely clear to me that, if the patch set changes in the
> future, the version number of the package will be distinctly incremented, as
> would be pretty standard for any other Linux distro.  Does each package have a
> minor version number, in the source and binary repositories, to allow
> distinguishing patch set changes, used in each build of every package?
>

There is a secondary version number, yes.

Packages have PKG_VERSION that shows the upstream version and 
PKG_RELEASE that is used to show changes on the LEDE side. If you see a 
package that lists version as 123-1, it's major version is 123 and its 
minor version is 1.

Packages with a timestamp use that instead of major version, and they 
still have a minor version.

for example  2016-09-21-42ad5367-1 where the last "1" is the minor version.

You can see all versions used in the first page of the table of packages 
in the wiki https://lede-project.org/packages/start

Or by browsing a Package.manifest in the package download folders 
https://downloads.lede-project.org/releases/17.01.0/packages/aarch64_armv8-a/base/Packages.manifest

> Perhaps, assuming that these distinct version numbers exist, and that these
> historic time-stamp or hash verified sources are archived somewhere and 
> available.

The hashes and time stamps of source archives or commits are written in 
the package's makefile in the git repository (either main repo or 
community package feeds), you can see full history of changes to that 
file with git.

There is a cache server that stores source archives because it's more 
convenient than having the build bots spamming upstream download servers 
and it is a convenient fallback if the upstream download disappears, it 
should keep stuff for a long while (as long as the release is supported 
for sure, as it is used by build bots).

it is here http://sources.lede-project.org/

Also OpenWRT's source cache server is used (as a fallback maybe) 
https://downloads.openwrt.org/sources/

> It sounds like the LEDE package management system has changed and improved 
> over
> the past months.  It would be great to see your description of the LEDE 
> package
> management system and build system on the wiki!

Ok, will move this to wiki in a few days.

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

Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency

[Alberto Bursi]

On 03/29/2017 06:08 AM, James Feeney wrote:
> Realize?  No - I'm still learning how this build process works in LEDE.  My
> impression is that you are distinguishing between "packages" and some other 
> type
> of thing, which the lede-project.org site seems to implicitly, and 
> generically,
> refer to as just "firmware" - even though a "package" is also a type of
> "firmware", and this "firmware" is also a type of "package".  I will infer 
> that
> you mean to distinguish between the "kernel and base filesystem" package from
> all other "packages".

LEDE is using the standard term for "package" in linux world, where a 
"package" is an archive containing a program or some scripts and its 
accompanying configuration and information used to integrate it in the 
system, installed by a package manager (opkg in this case), and the 
whole system is made of such packages assembled together around a Linux 
kernel.

Each package is compiled on its own and then when it's all done the 
packages are "installed" in a temporary root that will then be 
compressed to become the squashfs root in the device firmware.

Also the kernel is handled like a package for the build system, but 
since most devices expect it outside of root filesystem in various ways, 
it's added to the firmware image the way the device's bootloader expects it.


This is all pretty standard for any other Linux distro, Ubuntu, Debian, 
OpenSUSE, RHEL, whatever.

> You also seem to be implying that all the various "kernel and base filesystem"
> package builds are now precisely repeatable - even though this fact does not
> seem to be documented anywhere.

If you look at a random package makefile (the file defining settings for 
building a specific package)
https://github.com/lede-project/source/blob/master/package/utils/adb/Makefile

You will notice that it states the official download link for the 
sources, a SHA256 hash and a specific version for the package name.
On some other packages it will state git commit or other way to identify 
the same source to pull down and build.
They generally favor tarballs, archives with sources from official 
releases, but some upstream projects don't always have that.

In /patches folder of each package's folder you will find any patches 
that will be applied to the source after downloading it, before 
compiling, again the example package:
https://github.com/lede-project/source/blob/master/package/utils/adb/patches/001-create_Makefile.patch
There are also other folders for configuration files or for uci 
integration for each package that needs it (the example package does not).

The kernel's makefile is a bit more complex because of reasons, but you 
can see that it still uses the same structure,
pulling down the same kernel version (depending from device) every time.

https://github.com/lede-project/source/blob/master/package/kernel/linux/Makefile

Then all this stuff is compiled by LEDE's own toolchain, which is again 
handled like packages (see /toolchain and /tools) so you will always 
have the same compiler/tools as everyone else as they get downloaded 
from the same sources and at the same version.

When you run a "make" the LEDE build system will use your system's 
existing building infrastructure to compile the LEDE's toolchain first, 
and then use that to compile the packages. This also has the major 
benefit of not requiring the user to set up a cross-compiling toolchain 
that is rather annoying and relatively complex.

Is this enough for having repeatable builds?
I'm more like a long-time user so I don't know what "repeatable builds" 
mean beyond what I read from the internet, it seems this is more or less it.

>
> With respect to the lingo, "package feeds" and "project making the release", I
> have no understanding of the meaning of that statement.  Perhaps you could
> define precisely "package feeds" and "project making the release"?

Just as OpenWRT, there is a main project where the packages are 
maintained directly from core developers, and "package feeds" that are 
source repositories that contain additional packages, maintained by 
community (each package has its own maintainer).
This is LEDE's main repo (on github) https://github.com/lede-project/source

These are official package feeds (currently shared with OpenWRT):
https://github.com/openwrt/luci
https://github.com/openwrt/telephony
https://github.com/openwrt-routing/packages

Being "official feeds", the stuff from there will get compiled and 
offered in official download server, but it's not technically LEDE or 
OpenWRT proper, it's community-maintained.
The "package feed" system is designed to allow easy addition of your own 
custom feeds too in your custom firmware images, but you will have to 
compile them and host them on your own servers, of course.

If you look at the built packages here, 
https://downloads.lede-project.org/releases/17.01.0/packages/x86_64/

You find that they are divided by feed name.
Packages in "base" come from main 

Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency

[Alberto Bursi]

On 03/29/2017 12:19 AM, Gui Iribarren via Lede-dev wrote:

>i.e. if i install ubuntu 12.04 today, i expect to have exactly the same
>system than what i got if i installed ubuntu 12.04 at the time of its
>release

>if i want to get the fixes that happened after the time of original
>12.04 release, i'd install 12.04.1

Ubuntu 12.04 uses the same repositories, there is no split in 12.04.1, 
12.04.2 and so on.

That x.1, x.2 and so on is only a refreshed install iso with updates 
integrated.

So yeah, you could install 12.04 from the old-releases iso download folder
and it would be the same as it was when it was first released,
but then the updater will whine until you update Ubuntu with all the 
stuff that was updated in the repos,
as Ubuntu isn't supposed to be used like that.

> the equivalent in lede would be ..."opkg update && opkg upgrade *"?
> but it doesn't even really make sense, given squashfs and so on.

Many new and not-so-new devices with 8+ MiB flash aren't very 
space-limited (2+ MiB free space), so you can do that fine even with 
Luci and company with space to spare.

> all we want to do is create a firmware based on a specific LEDE release,
> and not fear that if we want to rebuild the exact same firmware in two
> months (or days!), we will get a different (broken) result

This is an issue of SDK not following properly the sources (because of 
reasons detailed by others already), imho it makes more sense to fix 
that than freeze everything.

-Alberto

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

Re: [LEDE-DEV] Kodi

[Alberto Bursi]

On 03/15/2017 11:57 AM, Daniel Engberg wrote:
> Hi,
>
> * Will anyone properly maintain all packages? We're already now
> struggling keeping the current repo somewhat up to date and
> maintainable, adding very niche packages certainly won't help.
>

Maintainership depends from each maintainer's dedication, what the 
community package feeds need is more rules on what happens to packages 
with absentee maintainers, not a firewall on entry (same thing I also 
said on Github when you posted this same argument).

That will only make the problem worse.

-Alberto

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

Re: [LEDE-DEV] Kodi

[Alberto Bursi]

On 03/15/2017 11:04 AM, Sorin Burjan wrote:
> Since OpenWRT/LEDE is mostly destined to routers, which don't have a
> HDMI or output port for display, how could someone use Kodi on a
> OpenWRT/LEDE router ?
>

Correct, Kodi is useless if the device does not have a display 
controller/GPU and a screen output port like hdmi/VGA, whatever.

But OpenWRT/LEDE supports raspi and also a bunch of allwinner-based 
boards (raspi clones or similar, look up "sunxi alwinner" on google), 
and also x86 devices (normal PC hardware).
And all these devices can output to a screen.

In the repo package feeds there are far more niche packages than Kodi, 
imho it would be a good addition. It will also show to the world that 
LEDE isn't just for routers anymore.

-Alberto

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

Re: [LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

On 03/08/2017 11:55 PM, Daniel Golle wrote:
> Hi Alberto,
>
> Try adding this patch to target/linux/kirkwood/patches-4.4 in addition
> to the changes in target/linux/kirkwood/config-4.4:
>
> --- a/arch/arm/mach-mvebu/Kconfig 2016-12-29 02:45:26.510509646 +0100
> +++ b/arch/arm/mach-mvebu/Kconfig 2017-03-08 23:50:16.924096508 +0100
> @@ -117,6 +117,7 @@
>  config MACH_KIRKWOOD
> bool "Marvell Kirkwood boards"
> depends on ARCH_MULTI_V5
> +   select ARCH_WANT_LIBATA_LEDS
> select CPU_FEROCEON
> select GPIOLIB
> select KIRKWOOD_CLK
> ---
>

Thanks for the patch! I had to adjust it a bit because it is not for 
kernel 4.4 but now I see the triggers!

root@LEDE:/# cat 
/sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
[none] ata1 ata2 nand-disk timer default-on netdev usbport

I will add a uci helper for that and then proceed with adding the leds 
in 01_leds file.

-Alberto

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

Re: [LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

On 03/09/2017 07:56 AM, Mathias Kresin wrote:
>
> In my opinion it would makes more sense to switch kirkwood to kernel 4.9
> and use the upstream LED Disk Trigger [0][1] which was introduced with
> kernel 4.8.
>

disk-trigger is not port-specific, it's not good for my usecase.

My kirkwood devices have 2 Sata leds (and two sata ports),
disk-trigger would flash both leds together for any sata activity.

Daniel's patch should allow me to have Sata1 led show activity on Sata1 
port, (and the same for Sata 2 led/port).

In stock firmware it works like that, and the leds are labeled on the case.

In general, most NAS devices have a sata led for each disk bay.

-Alberto

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

[LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

Hi, I'm trying to use the functionality added by this patch [1] (it 
should generate different led triggers for each Sata port) for a few 
kirkwood device that have multiple Sata Leds.

This patch is currently used only by some oxnas NAS devices, that seem 
to have not been fully ported to device tree.

After reading its description and the oxnas files I have added

CONFIG_ARCH_WANT_LIBATA_LEDS=y
CONFIG_ATA_LEDS=y

to the target/linux/kirkwood/config-4.4

but after I made a distclean, recompiled and booted the initramfs image, 
I can't see any sata trigger
---
root@LEDE:/# cat 
/sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
[none] nand-disk timer default-on netdev usbport
---

Does anyone have some ideas on why this does not work?

[1] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch

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

Re: [LEDE-DEV] Drumming up more interest in LEDE

[Alberto Bursi]

On 03/08/2017 02:12 AM, Mauro Mozzarelli wrote:
>
> To date still no progress and thus I do not see that giant step Philip
> mentions.
> I made another attempt today via git.
>
> Mauro
>

Wait times can be short but also quite long, up to months depending on 
when the core devs have some free time to look at your stuff.

So far most of what was sent on github (and made sense) was merged 
eventually. I don't track patchwork so I don't know about that.

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

Re: [LEDE-DEV] Need fix / advice / idea

[Alberto Bursi]

On 03/07/2017 11:09 PM, Denis Periša wrote:
> Alberto , thank you for insight!
>
> This device in latest "RouterBOOT" (as they call it) supports
> repartitioning to two partitions. But openwrt/LEDE (kernel actually)
> doesent support that - as per say -
>
> RouterBOOT booter 3.24
>
> RouterBoard 435G
>
> CPU frequency: 680 MHz
>   Memory size: 256 MiB
> NAND size:  64 MiB
> NAND partitions: 2
>
> Press any key within 1 seconds to enter setup.
> writing settings to flash... OK
>
> loading kernel from nand partition 1... kernel not found
> writing settings to flash... OK
>
> loading kernel from nand partition 0... OK
> setting up elf image... not an elf header
> kernel loading failed
> trying bootp protocol OK
> Got IP address: 192.168.111.91
> resolved mac address 00:XX:XX:00:06:XX
> Gateway: 192.168.111.2
> transfer started  transfer ok, time=1.24s
> setting up elf image... OK
> kernel loading failed - kernel does not support NAND partitions
>
>

No, that log says it didn't find a kernel in NAND in either partition 0 
or 1.

The repartitioning changes partitions in bootloader, but you need to 
erase the flash of these new partitions, then flash a new LEDE firmware 
in these new partitions. The bootloader should be able to do this.

Did you also edit that source file and recompile as I pointed out? That 
is needed for LEDE to actually recognize the new partitions once it is 
booted successfully.

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

Re: [LEDE-DEV] Please help with submitting contributions

[Alberto Bursi]

On 03/07/2017 05:48 PM, Mauro Mozzarelli wrote:
> Hello,
>
>
> I would like to make contributions to lede, but so far I bumped into a
> series of obstacles.
>
> So far I tried the following:
>
>
> git format-patch, then copy and paste into email -> was not accepted
>
> git send-email -> I do not know whether the patch was accepted, I did
> not receive any feedback
>
>
> Now I am trying also to follow what is on this page:
>
> https://lede-project.org/submitting-patches
>
> Under "Working with github"
>
> git clone https://github.com/lede-project/source.git
> git checkout -b 
>   
> git commit --signoff
> git push --all
>

That should be done on your account's fork of LEDE source, not on the 
lede repo directly. But the wiki paragraph is rather short and unclear.

I've just edited that paragraph to be actually useful.

https://lede-project.org/submitting-patches#working_with_github

-Alberto

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

Re: [LEDE-DEV] Need fix / advice / idea

[Alberto Bursi]

On 03/05/2017 04:25 PM, Denis Periša wrote:
> Hi all,
>
> I have situation where one of my devices (rb435g) has lot of bad
> sectors on (NAND) kernel partition.
>
> First of all, are those partitions physical? Can they be somehow
> re-partitioned by kernel cmd line or? I'm left with only under 1mb of
> usable space so I need to make kernel that fits that available space.
>
> Currently `make kernel_menuconfig` does not work, any news on that?
> Any ideas on how could I salvage this device to be usable?
>
> Network boot is a option, but that's last resort.
>
> Thank you!
>

You can try repartitioning through bootloader if you have serial 
console, see here
https://wiki.mikrotik.com/wiki/Manual:RouterBOOT

Then you may need to patch this file's partition list too and compile 
your own firmware, so LEDE actually uses the new partitions you have set 
up in the bootloader.
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-rb4xx.c#L148

The kernel is compiled by default to add this
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/config-4.4#L245
 

to the kernel command line added from bootloader.

I don't know that device so I can't tell you more specific info.

Note that in most devices there are hardware setup or bootloader 
partitions that should not be touched.

-Alberto

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

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

[Alberto Bursi]

On 03/02/2017 07:02 PM, Daniel Golle wrote:
> Hi!
>
> For your consideration: Please have a look at
> https://joeyh.name/blog/entry/removing_everything_from_github/
>
> This is not very surprising -- if power gets too concentrated it's
> only a matter of time to see it being abused. Hopefully we can pull
> stuff out there without implicitely acknowledging the new terms by
> doing that.
> I wonder how big player (torvald/linux.git and such) are going to
> react to this.
>
>
> Cheers
>
>
> Daniel
>

tl;dr I'm not seeing anything evil in Github TOS, those articles look 
quite suspicious.

An excerpt of the TOS
https://help.github.com/articles/github-terms-of-service/#d-user-generated-content

5. License Grant to Other Users

...

If you set your pages and repositories to be viewed publicly, you grant 
each User of GitHub a nonexclusive, worldwide license to access your 
Content through the GitHub Service, and to use, display and perform your 
Content, and to reproduce your Content solely on GitHub as permitted 
through GitHub's functionality. You may grant further rights if you 
adopt a license. (link to 
https://help.github.com/articles/adding-a-license-to-a-repository/#including-an-open-source-license-in-your-repository
 
)

--

This part above says that whatever you upload in a public repo is 
legally viewable and reproducible by anyone as long as it stays on 
Github (so the "reproducible" means "forkable in another Github repo"), 
if you add a (opensource) license you can grant more rights to others.

I'm not seeing how that breaks copyleft licenses.

and this is the part about Moral Rights (also discussed in the articles 
cited in your mail)

---

7. Moral Rights

You retain all moral rights to Content you upload, publish, or submit to 
any part of the Service, including the rights of integrity and 
attribution. However, you waive these rights and agree not to assert 
them against us, to enable us to reasonably exercise the rights granted 
in Section D.4, but not otherwise. You understand that you will not 
receive any payment for any of the rights granted in this Section.

To the extent such an agreement is not enforceable by applicable law, 
you grant GitHub a nonexclusive, revocable, worldwide, royalty-free 
right to (1) use the Content without attribution strictly as necessary 
to render the Website and provide the Service; and (2) make reasonable 
adaptations of the Content as provided in this Section. We need these 
rights to allow basic functions like search to work.

---

Please note the "REVOCABLE", and the "strictly as necessary to render 
the Website and provide the Service" and the "reasonable adaptations of 
the Content as provided in this Section"

which is probably connected to

---

4. License Grant to Us

Your Content belongs to you, and you are responsible for Content you 
post even if it does not belong to you. However, we need the legal right 
to do things like host it, publish it, and share it. You grant us and 
our legal successors the right to store and display your Content and 
make incidental copies as necessary to render the Website and provide 
the Service.

That means you're giving us the right to do things like reproduce your 
content (so we can do things like copy it to our database and make 
backups); display it (so we can do things like show it to you and other 
users); modify it (so our server can do things like parse it into a 
search index); distribute it (so we can do things like share it with 
other users); and perform it (in case your content is something like 
music or video).

This license does not grant GitHub the right to sell your Content or 
otherwise distribute it outside of our Service.

---

Again I'm not seeing anything evil.

I tend to see any accusatory article as highly suspicious unless they 
quote fully the bad parts of the documents they use as proof of 
wrongdoings, and neither of those you cited does. I might be spoiled 
brat, but that rule of thumb has never let me down.

-Alberto

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

[LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

On 02/27/2017 12:46 PM, Daniel Golle wrote:
> Will, I wrote this patch a long while ago (and use it on oxnas)
>
> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch
>

This is pretty cool, is there a reason why I can't find any board with 
the ARCH_WANTS_LIBATA_LEDS enabled in the kernel config in LEDE sources?
(even oxnas don't seem to have this)

I intend to try this on some kirkwoods that have more than one sata led 
(nsa310/325, goflexnet).

-Alberto

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

Re: [LEDE-DEV] replacing mountd with blockd - looking for testers

[Alberto Bursi]

On 02/27/2017 11:48 AM, John Crispin wrote:
>
>
>
> dont get this, why is a kernel patch required ?

That's how I saw some of such NAS stock firmwares (and some Debian/Arch 
for ARM targeting those devices) do.
Someone patched the sata driver (and the kernel) to create a "sata 
activity on port X" trigger that will show disk activity on "sata port 
X" (devices that have at least 2 sata ports, usually have a sata led per 
disk)

The Sata led trigger from upstream will trigger on ANY activity on Sata, 
so it's not useful to drive more than one Sata led.

> * off - no device attached
> * on - device attached
> * blink - device mounted
>

Hm, better than nothing.

I think the above led behaviours should be user-configurable though.

-Alberto

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

Re: [LEDE-DEV] CC to LEDE v17.01.0 on wrt160nl

[Alberto Bursi]

On 02/26/2017 03:44 PM, Torbjorn Jansson wrote:
> On 2017-02-26 15:35, Alberto Bursi wrote:
>>
>>
>> On 02/26/2017 03:20 PM, Torbjorn Jansson wrote:
>>> Hello.
>>>
>>> i just upgraded my wrt160nl from CC to the new LEDE stable release.
>>> things workes but i cant install anything.
>>>
>>> opkg update works at least one time, then i get errors trying to install
>>> something.
>>> errors like:
>>>  * xsystem: wget: vfork: Out of memory.
>>>
>>> any idea why?
>>>
>>
>> The device has 32MB of RAM and fixes to default system leave less ram
>> for opkg and other programs.
>>
>> Opkg was altered to use an order of magnitude less RAM so it could work
>> again, but that came too late for LEDE 17.01 release.
>>
>> According to jow, the opkg fix will get in the LEDE 17.01.1 that will
>> happen in March.
>>
>> see bugreport here
>> https://bugs.lede-project.org/index.php?do=details_id=120
>>
>> In the meantime, either use snapshot/trunk or stay on CC.
>>
>> -Alberto
>
> i see
> if i only could install the needed packages to get my usb stick working
> then i could enable the swap partition again and work around this.
>
>

In my testing (I also have some affected devices), swap on USB did not help.

-Alberto

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

Re: [LEDE-DEV] CC to LEDE v17.01.0 on wrt160nl

[Alberto Bursi]

On 02/26/2017 03:20 PM, Torbjorn Jansson wrote:
> Hello.
>
> i just upgraded my wrt160nl from CC to the new LEDE stable release.
> things workes but i cant install anything.
>
> opkg update works at least one time, then i get errors trying to install
> something.
> errors like:
>  * xsystem: wget: vfork: Out of memory.
>
> any idea why?
>

The device has 32MB of RAM and fixes to default system leave less ram 
for opkg and other programs.

Opkg was altered to use an order of magnitude less RAM so it could work 
again, but that came too late for LEDE 17.01 release.

According to jow, the opkg fix will get in the LEDE 17.01.1 that will 
happen in March.

see bugreport here 
https://bugs.lede-project.org/index.php?do=details_id=120

In the meantime, either use snapshot/trunk or stay on CC.

-Alberto

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

Re: [LEDE-DEV] [wiki]Table of packages is officially live!

[Alberto Bursi]

On 02/23/2017 10:48 PM, Baptiste Jonglez wrote:
> On Mon, Feb 20, 2017 at 06:52:15PM +0000, Alberto Bursi wrote:
>> The wiki feature showing what packages are in LEDE (and some information
>> about them) is now complete! Hooray! :)
>>
>> https://lede-project.org/packages/start
>
> Great, thanks Alberto!
>
> Here are a few questions and comments:
>
> - what is the difference between /packages/$pkg and /packages/pkgdata/$pkg?
>   e.g. https://lede-project.org/packages/tinc vs. 
> https://lede-project.org/packages/pkgdata/tinc
>   It seems that the first one is supposed to be created manually?
>

The first one is the page where people should add documentation about 
that package, how to use it, gotchas, and so on. That page can (should) 
be linked to user guide page too.
The creation of that page is guided by a template, I still need to start 
migrating things from OWRT wiki into this new system to see if the 
template is good enough, but maybe I can just advertise this feature 
already.

> - what would you think of moving the "category" column more to the right
>   in the tables, for instance after "source code"?  This way, the first
>   two columns are "name" and "version", which are for me the most important
>   information.

Category is useful for filters, the idea was that if you don't know the 
package names you will try with categories (helped by the cloud view 
above the table that list such categories).

This also relies on packages not sitting in major categories like for 
example there is like a few hundreds of assorted stuff in "utilities" or 
"network", but this has to be fixed in LEDE or package feed source.

I started doing that before I made the table of packages, now that I 
have a better view of the situation I can continue 
https://github.com/openwrt/packages/issues/3371

> - the description field is often quite large (look for instance at the
>   "network---vpn" category), so the table looks ugly.  I'm not sure how to
>   fix this though, maybe show just the beginning of the text, and show the
>   rest in a popup when hovering/clicking on the field?

Yeah, consider that the table is generated dynamically by a wiki plugin 
that has some funky limitations so that may not be possible.
Although I agree that descriptions aren't cool in the current table.

> - still with the description: it seems that line breaks are removed.  On
>   the other hand, word-wrapped text is ugly in HTML.  What do you think of
>   removing single line breaks, but treating two consecutive line breaks as
>   a  or even a new  block?

I don't think I can add html code in the description, and the table 
plugin wants all the cell content as a single line (hence no line 
breaks), also the space allocated to that field won't change much and 
thus we still get a ton of word-wrapping.

I need to test ways to enlarge the space in there, and think I'll have 
to enable wiki syntax parsing to get decent descriptions. I hope the 
performance impact isn't too bad.


> - your script does not seem to handle multiple maintainers? (e.g. 
> net/wireguard)

Yes, correct. I thought one maintainer was enough.
Should be easy to fix.

> - just a cosmetic note: why not use "/" instead of "---" to separate
>   between category and submenu?

Due to the fact that these names are used also as links in the datacloud 
view (above the table) and in the indexes, I cannot use slashes, nor 
spaces (spaces get replaced by "_" in the link), but I'm not that 
satisfied by the "---" either.

> Thanks again, other than these minor points it's a great tool :)
>
> Baptiste
>

Glad you like it. :)

-Alberto

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

[LEDE-DEV] [wiki]Table of packages is officially live!

[Alberto Bursi]

The wiki feature showing what packages are in LEDE (and some information 
about them) is now complete! Hooray! :)

https://lede-project.org/packages/start

The packages in the table/indexes are updated automatically from sources 
every sunday.

It is currently tracking Snapshot, will also track Releases when available.

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

Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?

[Alberto Bursi]

On 02/19/2017 01:34 PM, Mathias Kresin wrote:
> 19.02.2017 13:10, Alberto Bursi:

> I'm still the opinion that bringing up an unencrypted wireless without
> user interaction is really bad idea.
>
> The commit fixed the following problem: A user flashes one of the
> mentioned devices and is not aware that the flash is finished or (s)he
> get distracted in between. During this time period anyone can connect to
> the AP and can do harmful things.

What "harmful things" you had in mind?

That device with default config is disconnected from anything as it 
lacks ethernet, only thing that can be done is some kind of malware 
injection in the device itself from someone else in relative vicinity.

Assuming this is a threat at all, would this system stop this?
I doubt it. Such things would likely be automated bots, and a few 
seconds after the user pushes the button to enable the wifi to do his 
first configuration such bots will have already pwned the device.

Leaving wifi on in router/AP devices is bad and we all agree (people may 
forget the wifi open for ages, has happened and will happen again), but 
on these devices where there is no ethernet the user MUST connect and 
configure the device anyway, and this means he MUST touch wifi 
configuration anwyay and make his own choices on passwords and whatnot. 
It's very unlikely he will "forget" it open as the device will not work 
*at all* until he does.
And even if he does, the device will only be exposed to the 
abovementioned (highly unlikely) malware injections from a local 
attacker, not leave his internet free for all and also access to devices 
in his LAN.

LEDE does not enforce password complexity (nor having a password at 
all), nor limit number of login attempts, nor protect by default serial 
with login that are far more interesting attack vectors affecting far 
more devices.

Then we have restrictions for very specific corner cases like blocking 
access to uboot/bootloader envs and this 
wifi-disabled-that-requires-a-button-to-be-enabled.

The main reason I'm so vocal about this is that you are remapping 
buttons that would be more useful if left free for the user to set up 
for his own use, without having to patch the sources.

-Alberto

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

Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?

[Alberto Bursi]

On 02/19/2017 12:51 PM, Piotr Dymacz wrote:
> Hello,
>
> 2017-02-19 11:41 GMT+01:00 Daniel Golle :
>
> [...]
>
>>> Maybe a similar one that does what the "force enable wifi" script did
>>> would do the trick?
>>
>> Well, it's not as simple as that. We need to generate a config for
>> hostapd which matches the wifi hardware in terms of capabilities and
>> band and launch it and bring up the interface (configure IP address and
>> stuff) once hostapd comes up... possible, but quite a lot of work...
>
> If we assume that the problem is only inside wrong configuration
> applied to the device, reverting it back to the defaults (I assume
> here that default config for devices without Ethernet interface means
> also that the Wi-Fi is enabled by default) should be enough to bring
> back device to life.
>

After Mathias's commit (as noted by other mails above) the devices we 
are talking about have wifi disabled by default but you can enable it 
with the wps button.
https://github.com/lede-project/source/commit/bcfbeae79f799cf1087d692e4869589eb20d2080

Imho makes no sense as in most cases you will have to configure them 
anyway to be of any use (you can't just place them in a network with 
default config as they lack a ethernet port), so this "wifi off by 
default" and "remapping wps button to rfkill" imho is only an annoyance 
and removal of a potentially useful button that could be used for other 
things (enabling/disabling something else with scripts after user setup).

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

Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?

[Alberto Bursi]

On 02/19/2017 11:41 AM, Daniel Golle wrote:
> Hi Alberto,
>
> On Sun, Feb 19, 2017 at 10:12:04AM +, Alberto Bursi wrote:
>> On 02/19/2017 09:49 AM, Daniel Golle wrote:
>>> This still leaves us without failsafe mode and hard-to-access UART, so
>>> it'd make more sense to revive
>>> https://github.com/openwrt/packages-abandoned/tree/master/utils/restorefactory
>>> for those devices (or is there an easy way to have wifi enabled in
>>> failsafe mode?)
>> There are some dedicated scripts that get triggered to bring the device
>> in failsafe mode (just search with "failsafe" in LEDE's github), but I
>> don't know how exactly the startup scripts work so I can't really do it
>> myself.
>> For example this is a script that should allow failsafe by disabling
>> vlans in the onboard switch for a list of boards/targets that have this
>> issue
>> https://github.com/lede-project/source/blob/master/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
>>
>> Maybe a similar one that does what the "force enable wifi" script did
>> would do the trick?
>
> Well, it's not as simple as that. We need to generate a config for
> hostapd which matches the wifi hardware in terms of capabilities and
> band and launch it and bring up the interface (configure IP address and
> stuff) once hostapd comes up... possible, but quite a lot of work...
>

Then how was that "force enable wifi" script working in the first place 
if it just added a one-liner to uci setting to enable wifi by default?

Afaik failsafe mode is using squashfs /rom and a ram /overlay so it 
should work the same as a firstboot situation (where overlay is empty), 
so if it worked for firstboot it would work also for failsafe.

By searching around the sources, it seems that that basic uci 
configuration for a unencrypted wifi on LAN interface is written 
automatically (or can be summoned easily, I don't know how these scripts 
are triggered)
https://github.com/lede-project/source/blob/master/package/kernel/mac80211/files/lib/wifi/mac80211.sh

With the settings written by that script you only need to enable the 
wifi and everything will work.

-Alberto

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

Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?

[Alberto Bursi]

On 02/19/2017 09:49 AM, Daniel Golle wrote:
> Hi Dennis,
> Hi Alberto,
>
> This still leaves us without failsafe mode and hard-to-access UART, so
> it'd make more sense to revive
> https://github.com/openwrt/packages-abandoned/tree/master/utils/restorefactory
> for those devices (or is there an easy way to have wifi enabled in
> failsafe mode?)
>

There are some dedicated scripts that get triggered to bring the device 
in failsafe mode (just search with "failsafe" in LEDE's github), but I 
don't know how exactly the startup scripts work so I can't really do it 
myself.
For example this is a script that should allow failsafe by disabling 
vlans in the onboard switch for a list of boards/targets that have this 
issue 
https://github.com/lede-project/source/blob/master/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips

Maybe a similar one that does what the "force enable wifi" script did 
would do the trick?

-Alberto

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

Re: [LEDE-DEV] Help wanted with testing opkg improvements

[Alberto Bursi]

On 02/18/2017 11:12 PM, Alberto Bursi wrote:
>
>
> On 02/18/2017 03:49 PM, Jo-Philipp Wich wrote:
>> Hi again,
>>
>> I fixed the "OFF" error and the package size handling.
>>
>> Updated patches are:
>>
>> https://git.lede-project.org/71ab6d6.patch
>> https://git.lede-project.org/b04957d.patch
>>
>> ~ Jo
>>
>
> Ok, now it is not sluggish, and installing packages with some
> dependencies like transmission-daemon-mbedtls, or bigger ones like Samba
> and minidlna works without causing OOMs or other breakage.
>
> I would say it's working fine here. Thanks for the fix. :)
>
> -Alberto
>

I tested the above with SSH and with Luci Software installation page.

-Alberto

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

Re: [LEDE-DEV] Help wanted with testing opkg improvements

[Alberto Bursi]

On 02/18/2017 03:49 PM, Jo-Philipp Wich wrote:
> Hi again,
>
> I fixed the "OFF" error and the package size handling.
>
> Updated patches are:
>
> https://git.lede-project.org/71ab6d6.patch
> https://git.lede-project.org/b04957d.patch
>
> ~ Jo
>

Ok, now it is not sluggish, and installing packages with some 
dependencies like transmission-daemon-mbedtls, or bigger ones like Samba 
and minidlna works without causing OOMs or other breakage.

I would say it's working fine here. Thanks for the fix. :)

-Alberto

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

Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?

[Alberto Bursi]

On 02/18/2017 07:40 PM, Daniel Golle wrote:
> Hi Dennis,
>
> On Sat, Feb 18, 2017 at 06:32:53PM +0100, Dennis Schneck wrote:
>> Hello,
>> is there a Image for TP-Link TL-WA854RE ?
>
> Due to the lack of an Ethernet port the device is currently very hard
> to support properly. It's also known to have a very hard to access
> UART, so it's easy to brick and hard to revive... I just wouldn't
> recommend anyone to buy such a thing, chances are high that you'll
> end up with an unusable device sooner or later.
>
> Anyway, for proper support we'd need either:
>  * adding wireless interface being enabled as AP
>  * mimic WPS button functionality of stock firmware
>
> Both are not trivial in the current framework and would require
> changing the way wireless configuration is initially being generated.
> While this is generally an area which is being worked on, I'm not aware
> of any other devices having wireless enabled after being flashed
> initially.
> As a hack or temporary work-around, this is easy to achieve though.
> Ufo (CC'ed) put some work into adding board support for this device,
> maybe he can point you to his current work-in-progress patch.
>
>
> Cheers
>
>
> Daniel
>

There are some such wifi-only devices supported like the "D-Link 
DCH-M225 Wi-Fi Audio Extender", and it seems they have wifi enabled by 
default with this commit:
https://github.com/lede-project/source/commit/0d5277f73fe4071df4273784e3252d520cef8a6e

-Alberto

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

Re: [LEDE-DEV] Help wanted with testing opkg improvements

[Alberto Bursi]

On 02/17/2017 08:14 PM, Jo-Philipp Wich wrote:
> Hi again,
>
> my previous change was incomplete, please use the following two changes
> for testing:
>
> https://git.lede-project.org/71ab6d6.patch
> https://git.lede-project.org/e9bd98e.patch
>
>
> Bye,
> Jo
>

Ok, flashed on my ar71xx device. Opkg is noticeably slower (there is a 
5-second delay on "opkg install") but it is not that bad.
Also "opkg list" is slower, (before it was all done in a second or so, 
now it needs like 10 seconds to write the full list).

After I ran the opkg list I saw this error
opkg_conf_deinit: Couldn't unlink OFF: No such file or directory.

The install fails because opkg is thinking some packages occupy (much) 
more space than they actually do.
I'm pretty sure block-mount or f2fs-tools don't really need 5000+ kb of 
flash space as in the following output.

root@lede:/# opkg install f2fs-tools
Installing f2fs-tools (1.7.-1) to root...
Collected errors:
  * verify_pkg_installable: Only have 3740kb available on filesystem 
/overlay, pkg f2fs-tools needs 5365
  * opkg_install_cmd: Cannot install package f2fs-tools.
  * opkg_conf_deinit: Couldn't unlink OFF: No such file or directory.

root@lede:/# opkg install block-mount
Installing block-mount (2017-02-11-7d78836-1) to root...
Collected errors:
  * verify_pkg_installable: Only have 3740kb available on filesystem 
/overlay, pkg block-mount needs 5858
  * opkg_install_cmd: Cannot install package block-mount.
  * opkg_conf_deinit: Couldn't unlink OFF: No such file or directory.


-Alberto

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

Re: [LEDE-DEV] Help wanted with testing opkg improvements

[Alberto Bursi]

On 02/17/2017 08:14 PM, Jo-Philipp Wich wrote:
> Hi again,
>
> my previous change was incomplete, please use the following two changes
> for testing:
>
> https://git.lede-project.org/71ab6d6.patch
> https://git.lede-project.org/e9bd98e.patch
>
>
> Bye,
> Jo
>

I can't seem to apply the second patch on a clean git clone of the LEDE 
sources, this is the error

 > git apply e9bd98e.patch
error: patch failed: package/system/opkg/patches/001-ship-pkg-m4.patch:1
error: package/system/opkg/patches/001-ship-pkg-m4.patch: patch does not 
apply

I'm git cloning your staging tree where these commits are already in, at 
https://git.lede-project.org/lede/jow/staging.git
so I can try this out on my TL-WR1043NDv1 (ar71xx) device that has 32MiB 
of RAM.

-Alberto

___
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

[Alberto Bursi]

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.

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

Btw, for console access (serial or TTL or whatever) there is no login 
even if you have set a password afaik.

-Alberto

___
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

[Alberto Bursi]

On 02/17/2017 12:51 PM, John Crispin wrote:
>
>
> regardless of you liking my use case or not its still a NAK
>
>   John
>

Who cares, really. I just posted my opinion.

-Alberto

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

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

[Alberto Bursi]

On 02/15/2017 05:45 PM, Jo-Philipp Wich wrote:
> Hi,
>
> To get final fixes into the release please mention Git commits you like
> to see cherry-picked in to lede-17.01  until Sunday, the 19th.
>

a9d347c11c34e48d17e1a4902a56d1f2f577bfab
uboot-kirkwood: fix goflexhome/net bootcommand

-Alberto

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

Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!

[Alberto Bursi]

On 02/05/2017 05:37 PM, Daniel Golle wrote:
> Hi Alberto,
> It's the first time I'm trying to get work compensated by the community
> and I'm not sure whether kickstarter is the right way to go -- though
> I've written clearly that the initial goal would cover one night of
> hacking on rt2x00 and additional funds would pay for additional hours,
> I'm not sure whether everyone got that. Maybe I'll just need to stop
> at some point today, because by now, I've been working on MT7620-
> related stuff for more hours than I'd ever work for that amount of
> money. Surely, my motivation isn't purely economic in that case, I
> actually have some idealistic and educational goals as well, which is
> also why I started upstreaming the rt2x00 patches. However, I also
> don't want to leave the impression that I'd work for less than minimum
> wage on stuff which I'm only capable of doing because I've been hacking
> on kernel code for something like a decade by now. And as it looks like
> right now, this can work for a weekend, but cannot become a habbit,
> simply because I can't afford that luxury if it only pays the minimum
> I've been asking for initially -- probably I just need to create new
> projects on kickstarter for each phase of work, but that also seems
> like a lot of overhead given that I'd rather work on code than spending
> time on a rather annoying JavaScript-application running in my browser
> and eating half of the RAM of my machine...
>
> So if you now any better method or service than kickstarter which
> allows me to follow the street-musician-protocol while hacking on
> FOSS code, that'd be highly appreciated.
>
>
> Cheers
>
>
> Daniel
>

IMHO crowd-funding is a good way for FOSS.
It allows people that are unable to actually develop to help out by 
sending money so that those that can develop can do so more freely.
As long as this concept is stated clearly, everything should be fine.
Afaik it's unrealistic to expect top pay out of it, but it will help out 
on things you are probably going to do anyway.

Crowd-funding in general requires you to actually devote some time to 
post somewhat regular updates (with proof of what you did if possible, 
for FOSS it's easy as you just push sources on a public repo so people 
can see them and test them maybe).
The idea is keeping the people informed of what you did with their 
money. You can see this if you look at any other half-decent 
crowdfunding project on Kickstarter or everywhere else.

Kickstarter usually favors projects that drop from the sky and storm the 
place weapons-blazing, so to speak. It isn't for everyone.
Like for example this, the Krita open source painting software (this is 
the third round they get decent founding for yearly development on 
kickstarter) 
https://www.kickstarter.com/projects/krita/krita-free-paint-app-lets-make-it-faster-than-phot
You can see that they posted lots of content about what they would do, 
and also stretch goals and whatever, and used many images too, big 
goals, great hopes, hype everywhere. This helps attract attention and 
donations in a relatively short time.

For example, kickstarter has "stretch goals", goals that unlock more 
features beyond the one for the main goal. You might add that for every 
XXX$ money sent you will be able to devote another weekend or something 
to look at it or whatever. So you can keep people motivated in sending 
donations.

For your need to keep the overhead low for a potential next run, I'd 
personally recommend to look at the Patreon site instead. 
https://www.patreon.com
It is a crowd-funding site born in 2013 for paying artists (and is quite 
big in this), but is also being used by software developers.

The main difference with kickstarter is that its main concept is 
allowing (many) people to set up a (relatively small) monthly donation 
and become "patrons" of an artist (kinda like in the old times where 
artists were hosts of a single rich patron, notice the similarity with 
"Patreon" name of the site). It thus requires less fanfare than 
Kickstarter, but regular updates are still good.

I'd like to cite as an example of "using Patreon right" Kent Overstreet 
(he made bcache, currently in mainline linux and also in production use) 
that is using it to get some support for his next project, bcachefs 
https://www.patreon.com/bcachefs
As you see he is getting around 870$ a month, which isn't that bad, but 
of course it's not anywhere near top pay for his skills.

As a last point, I'd like to repeat what I said in the mail you 
responded to. Every now and then it's good to send a mail to the main 
open source news sites with updates or whatnot so they can post a news 
article about you and attract some attention (and donations/patrons) on 
your project.

-Alberto

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

Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!

[Alberto Bursi]

On 02/04/2017 07:11 PM, Daniel Golle wrote:
> Hi Weedy,
>
> On Fri, Feb 03, 2017 at 07:49:22PM -0500, Weedy wrote:
>> On 1 February 2017 at 15:29, Jamie Stuart  wrote:
>>> Hello LEDE / OpenWRT devs,
>>>
>>> I am requesting your help. First a little background…
>> ...
>>> This a known issue with the chipset and seems to have been round for years.
>>> We are currently building on LEDE trunk and still the issue persists.
>>>
>>> We are not driver developers, so my question is whether anyone with
>>> knowledge can help and provide a proper fix for this issue?
>>
>>
>> You will probably have the most luck posting a bounty on the linux
>> wifi mailing list.
>
> As a response to the many issues and obvious code quality problems in
> the patch adding support for MT7620 to rt2x00 I started a kickstarter
> project to fund an afternoon or two (depending on the amount people
> throw into my hat) of focussing on rt2x00 running on MT7620:
>
> https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede
>

Might be a good idea to send a mail to Micheael Larabel, the guy running 
Phoronix.com (linux-oriented news and benchmarks site), so he can write 
an article to raise awareness for that kickstarter project.
http://www.phoronix-media.com/?k=contact
Or other linux-oriented news sites that might be interested.

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

Re: [LEDE-DEV] Is there a location for utility scripts?

[Alberto Bursi]

On 02/01/2017 06:13 PM, Rich Brown wrote:
> A multi-part question:
>
> 1) Does the LEDE community have any favorite scripts that might be included 
> in the basic LEDE distribution?
>
> For example, I wrote a "getstats.sh" script 
> (https://github.com/richb-hanover/OpenWrtScripts/blob/master/getstats.sh) 
> that collects a consistent set of information to be included in trouble 
> reports. I did this to avoid multiple back-and-forths with people reporting a 
> problem, asking for this info, then that info, then still more...
>
> Would this script be useful to have as a "standard tool" in LEDE? (If the 
> script is pre-installed, then it's simple to ask the person to include that 
> information in a bug report.)
>
> 2) Are there other similar scripts that would make your life easier?
>
> 3) If so, where should such scripts live?
>
> Thanks.
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>

I think a good place might be a dedicated http download link from the 
wiki server so people can wget them from their router.

I'm thinking about the Microsoft's automated registry editing programs 
they offer in their help pages about various Windows issues, so people 
download the program and run it and it will do what the (sometimes 
lenghty and complex) help page says.

-Alberto

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

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[Alberto Bursi]

On 02/03/2017 11:40 AM, Daniel Golle wrote:
> Hi Stas,
>
> Obviously you could easily avoid that legal requirement by just not
> offering a free download of the binaries, so don't get me wrong, I
> do appreciate your openness! Yet, it'd be great if we had a shared
> codebase for TDMA instead of a growing number of competing
> implementations (ubnt, mikrotik, Deliberant's iPoll, NETSHe, ...) each
> being developed behind closed doors.

Not gonna fly, they are making it for money, they don't want a "shared 
codebase", they want to sell their NETSHe.

What might be interesting for a commercial entity like them is that if 
they do like Qt does (dual-license, either proprietary for paying 
customers or GPL for everyone else, contributors sign a license 
agreement that allows Qt to do this dual licensing), the NETSHe's 
position will be strenghtened.
They will receive a boost for public awareness and contributions, as 
open firmwares and Linux OS will likely use their implementation by 
default so that's what people will be more likely to 
know/learn/test/contribute to.
While since many companies don't like GPL they will still make money 
selling proprietary-licensed code to them.

Assuming it isn't just a massive GPL violation where they just do ugly 
hacks to the GPLed drivers and make these new version closed source, anyway.
I'm probably very biased but tricks like the above are very very common.

-Alberto

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

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[Alberto Bursi]

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.

-Alberto

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

Re: [LEDE-DEV] brcm47xx legacy image building issues

[Alberto Bursi]

On 01/03/2017 09:37 AM, Eric Masson wrote:
> Rafał Miłecki  writes:
>
> Hi Rafal,
>
>> I just downloaded and extracted
>> https://downloads.lede-project.org/snapshots/targets/brcm47xx/legacy/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64.tar.xz
>>
>> I entered lede-imagebuilder-brcm47xx-legacy.Linux-x86_64 and executed your 
>> command. It worked fine.
>>
>> I see 3 options:
>> 1) Something got fixed in "Tue Jan 3 06:46:26 2017"
>> 2) You are doing something extra you didn't describe
>> 3) There is some issue specific to your host
>
> Probably 1 as everything went fine with today's imagebuilder "Tue Jan 3
> 06:46:26 2017".
>
> At least both previous brcm47xx imagebuilder were causing the reported
> issue.
>
> Thanks a lot for your help.
>
> Regards
>
> Éric Masson
>

A possible explanation is that you issued the command while the 
buildbots on the build server were still building some packages for your 
target, so the imagebuilder could not find them in the repo.

Also in forums people report similar "mysterious" issues about 
installing packages that disappear after less than a day.

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

Re: [LEDE-DEV] sqm-scripts change GitHub link to https:// instead of git://

[Alberto Bursi]

On 01/03/2017 02:02 AM, Nick Kamenyitzky wrote:
> Is there any reason that the sqm-scripts makefile has a git:// link
> instead of a https:// link?  At my office git:// doesn't work but
> https:// does.
>
> Should this be something that is standardised or considered?
>
>
>
> Kind Regards,
>
> Nick Kamenyitzky
>
> -
> Email: n...@kamenyitzky.com.au
> -
>

issue fixed in the package repo
https://github.com/openwrt/packages/pull/3741

-Alberto

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Alberto Bursi]

On 01/02/2017 07:36 PM, Philip Prindeville wrote:
>
>
> Right, this is why I’m trying to create a new target (or subtarget) called 
> “xeon” which is optimized for Xeon targets and leverages the on-chip 
> crypto-accelerators.
>
> We’ve come a long way since the Athalon-64 (k8) in 2004.
>
> -Philip
>

Wait a sec, what you mean exactly for "on chip crypto accelerators"?
If you mean AES-NI there was already a discussion about that in the 
mailing list, see here 
http://lists.infradead.org/pipermail/lede-dev/2016-October/003545.html

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

Re: [LEDE-DEV] Image Wizard for LEDE?

[Alberto Bursi]

On 01/02/2017 11:23 AM, Jo-Philipp Wich wrote:
> Hi,
>
>> Freifunk (or another german site about wifi) also has a webinterface for
>> the Image Builder. I would really like to have that too.
>
> Count me in, I also support this idea. I can lend a hand with
> implementing stuff.
>
> ~ Jo
>

Nice, thanks for the offer. I was planning to try setting it up in a VM 
locally after I finished the automated package list indexing script for 
the wiki (within a month or so).
I had a look at the docs and it should only need some configuration to 
work for LEDE/OWRT, but since I have yet to try it I don't know if there 
are limitations or issues yet.

If you want to have a look...

This is the site:
http://imagebuilder.augsburg.freifunk.net/

Source and installation docs are here:
https://github.com/weimarnetz/meshkit



-Alberto

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

Re: [LEDE-DEV] Blackhole routes and other tidbits on the network configuration wiki page

[Alberto Bursi]

On 12/31/2016 11:33 PM, Philip Prindeville wrote:
> I was going over the “Network configuration” page on the wiki and it’s a 
> little thin on routes.  In particular, it implies that for a route you always 
> need interface/target/netmask/gateway… but in the case of type=blackhole, a 
> gateway doesn’t really seem applicable.
>
> So would you have:
>
> config route
>   option interface ‘lan’
>   option target ‘192.168.1.99’
>   option netmask ‘255.255.255.255’
>   option type ‘blackhole'
>
>
> instead?  For that matter, do you really even need the “interface” part?
>
> Who owns that wiki page?  I was trying to figure that out using the wiki 
> itself but couldn’t figure out how.
>
> -Philip
>

There is no "owner", although you can see the people that modified it if 
you click on the little clock icon on the right.

I'm "bobafetthotmail" wiki user, I ported that wiki page more or less 
as-is from OpenWRT wiki.
Since I know little of routing (in LEDE or otherwise) I just gave it its 
own article, splitting it from a larger page with many networking 
topics, but I could not really change it or add anything to it.

If you want to improve it, please register/login in the wiki and do so.

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

Re: [LEDE-DEV] Image Wizard for LEDE?

[Alberto Bursi]

On 12/28/2016 06:50 PM, Moritz Warning wrote:
> Hi,
>
> would the LEDE Community be interested in a firmware wizard like this one?
>
> https://firmware.darmstadt.freifunk.net/
>
> Sources: https://github.com/freifunk-darmstadt/gluon-firmware-wizard
>
> It would take some time to add matchers for most of the images.
> The current problem is that it is quite hard to find the correct image.
> Current image names can be rather confusing for the ordinary user.
>
> - mwarning
>

I like it. It's far less clunky than using the dedicated view of the 
wiki ToH https://lede-project.org/toh/views/toh_fwdownload

As for the adding matchers in the list file, you can (should) probably 
automate that with a script that parses the Makefiles from the source 
(and run that periodically to keep the list updated).

Freifunk (or another german site about wifi) also has a webinterface for 
the Image Builder. I would really like to have that too.


-Alberto

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

[LEDE-DEV] ppc44x: current snapshot stuck at 14 December

[Alberto Bursi]

as subject, ppc44x images and kmod packages were compiled last time 14 
December, while everything else is last compiled around 28 December.
https://downloads.lede-project.org/snapshots/targets/ppc44x/generic/

I personally don't need them, this is just an inconsistency I found.

Also, I don't find where are device build failure logs.

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

Re: [LEDE-DEV] [lede] Patch notification: 1 patch updated

[Alberto Bursi]

Same here. Received a patch notification for the same patch, and it 
isn't my work either.

-Alberto

On 12/28/2016 11:59 AM, Ben Mulvihill wrote:
>
> There seems to be an issue with patchwork notifications. I received
> the one below addressed to be as the patch submitter.
>
> The patch was actually submitted by Christian Lampeter and is nothing
> to do with me at all.
>
> On Wed, 2016-12-28 at 09:50 +, Patchwork wrote:
>> Hello,
>>
>> The following patch (submitted by you) has been updated in patchwork:
>>
>>  * lede: [LEDE-DEV] Help needed: IP175D + RT3662 issues on a "new" device
>>  - http://patchwork.ozlabs.org/patch/708718/
>>  - for: LEDE development
>> was: New
>> now: Changes Requested
>>
>> This email is a notification only - you do not need to respond.
>>
>> Happy patchworking.
>>
>> --
>>
>> This is an automated mail sent by the patchwork system at
>> patchwork.ozlabs.org. To stop receiving these notifications, edit
>> your mail settings at:
>>   http://patchwork.ozlabs.org/mail/
>>




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

[LEDE-DEV] Why my kernel does not find the rootfs in a ubi partition?

[Alberto Bursi]

I'm trying to add support for a ZyXEL NSA310 (kirkwood-based NAS), but 
the kernel does not find the rootfs in the ubi.

The image has kernel+rootfs(squashfs)+rootfs_data(ubifs?) in ubi, built with
FILESYSTEMS := squashfs
IMAGES += factory.bin
IMAGE/factory.bin := append-ubi
KERNEL_IN_UBI := 1

If I boot the initramfs (ramdisk) system image while there is a ubi 
image flashed to nand, it gives this error while booting

[ 1.070706] UBI: auto-attach mtd2
[ 1.073868] ubi0: attaching mtd2
[ 1.083812] UBI: EOF marker found, PEBs from 28 will be erased
[ 1.089971] ubi0: scanning is finished
[ 1.093994] ubi0 error: ubi_read_volume_table: the layout volume was not 
found
[ 1.101458] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -22
[ 1.108559] UBI error: cannot attach mtd2

but since ubi isn't necessary for the initramfs image, it works fine and 
I get to system console.

If I flash the image to nand (and set uboot for booting from ubi, with 
NO bootargs passed to the kernel), the kernel boots until it finds the 
same error above, and then it posts this

[ 1.605331] VFS: Cannot open root device "(null)" or unknown-block(0,0): 
error -6
[ 1.612865] Please append a correct "root=" boot option; here are the 
available partitions:
[ 1.621268] 1f00 1024 mtdblock0 (driver?)
[ 1.626346] 1f01 512 mtdblock1 (driver?)
[ 1.631439] 1f02 129024 mtdblock2 (driver?)
[ 1.636521] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)

And of course auto-reboots.

I've tried with bootargs like ubi.mtd=2 but with any bootarg about root= 
or ubi it simply hangs and does not even start the kernel (shortly after 
uboot hands over to the kernel the device resets).

the ubi partition seems to be OK according to uboot. Any help 
appreciated. :confounded:

NSA310> ubi part ubi
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=2", size 126 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 1008, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence 
number: 1235565284
ubi0: available PEBs: 0, total reserved PEBs: 1008, PEBs reserved for 
bad PEB handling: 20

NSA310> ubi info
UBI: MTD device name: "mtd=2"
UBI: MTD device size: 126 MiB
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: number of good PEBs: 1008
UBI: number of bad PEBs: 0
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 3
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 1008
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 1/0

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

Re: [LEDE-DEV] subversive idea for cert alerts

[Alberto Bursi]

On 12/24/2016 12:21 AM, Dave Taht wrote:
> I think a cool subversive thing people could do would be to have a set
> of stickers we could apply to routers in a retailer that had a LARGE
> WARNING label pointing to the relevant cert alert - and including
> steerage to a public firmware like lede that fixed the problem for
> that model.
>
> http://forums.theregister.co.uk/forum/1/2016/12/23/netgear_router_vuln/
>

Do you really want to link open source firmwares (LEDE or whatever) with 
these kinds of lame teenage vandalism?
(because attacking stickers to stuff on sale is vandalism, in case you 
don't know)

The things that people do in the name of "activism" these days...
Imho that's a plain bad idea, not "cool" nor "subversive" in any way.

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

Re: [LEDE-DEV] Release planning

[Alberto Bursi]

> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> - Are there any outstanding changes?
>Is there important changes we should wait for before branching the
>release? Is there pending stuff in the staging trees which should
>absolutely go into the first release?
>

Imho an important issue that has to be addressed before release is the 
OOM issues opkg has in devices with 32MiB of RAM.

LEDE supports a around 380 devices with that ram. (according to the ToH [1])
Around half of these devices (around 180) seem to have 8 MiB or even 
more Flash, so it's reasonable to expect that opkg works for them.

Many people upgrading from OWRT will start getting hard OOM failures 
when using opkg on devices where it worked fine in OWRT CC.


In the bug thread [2] I proposed a possible solution that should be easy 
to implement for someone that knows opkg source already (I also have a 
32 MiB device ready to test any patch):

In low ram devices have opkg download package lists every time it needs 
to read them, don't keep them in tmpfs.
Like "download -pipe- extract -pipe- read" without passing from tmpfs.
This will murder its performance as it will need to wait for the 
download of all lists each time you use it, but should keep it usable.

This trick shouldn't trigger the OOM as the current workaround is to 
comment out some of the feeds (telephony and luci for example) from the 
opkg feed list so they aren't downloaded, and that works fine.
This might even allow opkg to work in devices with 16 MiB of ram.

1. 
https://lede-project.org/toh/views/toh_extended_all?dataflt%5BRAM+MB*%7E%5D=32
2. 
https://bugs.lede-project.org/index.php?do=details_id=120_watched=1%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=open%5B0%5D=%5B0%5D=

-Alberto

___
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

[Alberto Bursi]

On 12/21/2016 09:42 PM, Dave Taht wrote:
> On Wed, Dec 21, 2016 at 12:29 PM, David Lang  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.
>

+1 for this. OpenWRT brand isn't 100% positive recognition, it has some 
downsides too. Many people (I know and/or have seen around the internet) 
were discouraged from contributing or using it due to the weaknesses of 
OpenWRT project.

I like more the LEDE branding for this reason. It conveys that it is 
significantly different, possibly for the better, from OpenWRT project.

But I don't have enough information to say for sure what is the better 
brand to keep, so this is just my opinion.

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

Re: [LEDE-DEV] making new package lists for LEDE wiki's bot

[Alberto Bursi]

On 12/17/2016 04:14 PM, Alberto Bursi wrote:
> Lately the "Source: " entry was removed from package lists.
> This is breaking the script I use to generate the package lists for the
> LEDE wiki's table of packages [1] and package indexes [2].
>

Hmm, found the file that removed that line (and others I didn't notice 
yet), it's in scripts/ipkg-make-index.sh.

I can easily modify the file package/Makefile to generate a second 
package list with only the info I need.

I have yet to figure out how to add other info to it and if it is 
possible at all without polluting the "control" file in the package, as 
it seems Category and Submenu aren't available in the "control" file 
read by ipkg-make-index.sh.
It seems the control file is generated by scripts/metadata.pm or some 
other Perl script calling it, and I don't know Perl syntax so I can't 
get much further.

-Alberto



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

[LEDE-DEV] making new package lists for LEDE wiki's bot

[Alberto Bursi]

Lately the "Source: " entry was removed from package lists.
This is breaking the script I use to generate the package lists for the 
LEDE wiki's table of packages [1] and package indexes [2].

My script relies on that line to find the makefiles and download them 
from github, so it can read the package's Category and Submenu to 
categorize them in the same way they are shown in make menuconfig.

Many packages are generated using variable names in makefiles, trying to 
find their makefile now is very complex.

The "Source:" line was bloat for opkg, so I'm asking if it would be 
acceptable to have the build system generate a special package list 
exposing the info I need for the LEDE wiki.

I'm thinking about having Category and Submenu written already in there 
so I can also skip the "download and read makefiles" part in the script.

Can someone with more in-depth knowledge of the build system give me 
some directions?

Would it be an acceptable addition for LEDE as that's not directly 
needed by LEDE itself but by a bot running in the wiki server?

-Alberto

1. https://lede-project.org/packages/start
2. https://lede-project.org/packages/index/start
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Some Broadcom wifi chipset datasheets released by Cypress

[Alberto Bursi]

Some broadcom wifi chipsets datasheets are being released free of NDA by 
a company called Cypress that acquired the IoT division of Broadcom.

original article from here 
http://www.phoronix.com/scan.php?page=news_item=Cypress-Publishing-Broadcom

datasheets here 
http://www.cypress.com/search/all?f[0]=meta_type%3Atechnical_documents[1]=resource_meta_type%3A575[2]=field_related_products%3A110101

"data-sheets on the BCM88335 802.11ac, BCM89359 802.11ac, BCM43143 
802.11 b/g/n, CYW20736 Bluetooth, BCM43362, BCM4334, and much more. The 
specifications appear to be fairly thorough and for some of the chips 
include over 100 pages of information. All of this public information 
will hopefully be useful in improving some of the Broadcom wireless 
Linux drivers.

Cypress acquired Broadcom's IoT business this summer for $550 million USD."

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

Re: [LEDE-DEV] Package data on the wiki

[Alberto Bursi]

On 11/16/2016 08:01 AM, Baptiste Jonglez wrote:
> Hi,
>
> I discovered that tons of packages now have their own page in the wiki,
> which is nice.  It looks automated, what is the source of the data?
>
> Here are a few observations:
>
> - I'm not sure the list of architectures is very relevant, and it clutters
>   the page a lot.  See for instance 
> https://wiki.lede-project.org/pkgdata/htop-snapshot
>
> - Regarding https://wiki.lede-project.org/pkgdata/wireguard-tools-snapshot
>   the link to the "Source code" is wrong, it points to utils/openocd instead
>   of net/wireguard.  Also, a lot of metadata have not been imported, like
>   version or dependencies.
>
> - There is no page for the kmod-wireguard package, which is built
>   alongside wireguard-tools.  In fact, there seems to be no kmod-*
>   packages at all.
>
> Baptiste
>
>

The project is a work-in-progress to have a Table of packages (which 
does not mean just a huge table), you can find the discussion with more 
details in the forum thread here.

https://forum.lede-project.org/t/lede-table-of-packages-good-or-bad/123/86 
(btw, the script source shown in the forum thread is an old revision, I 
basically rewrote it to allow decent performance)

and the WIP Table of Packages here 
https://wiki.lede-project.org/packages/start

The data is imported by a script that is reading the same package lists 
used by opkg in a live LEDE system, then integrated with data scraped 
from the Makefiles it downloads from github (mostly categories and 
submenus, this wasn't working when I uploaded package data in the wiki, 
but now it works fine for most packages).
The plan is to eventually move the script on the wiki server itself and 
run this automatically to keep the package data updated weekly or something.

The package data you find on the wiki at the moment is a dummy, loaded 
with a immature and buggy script just to test the wiki's ability to show 
such data in a meaningful/performing way (and see if it was a good idea 
or not).

I know that the information is wrong/missing/incorrect in many cases, 
that's the reason we didn't add any link to these pages in the main wiki 
yet.

-Alberto

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

Re: [LEDE-DEV] adding LEDE support for board DLINK DWR-512-B

[Alberto Bursi]

On 11/13/2016 09:54 PM, Giuseppe Lippolis wrote:
> I try to follow the notes of Alberto,
> https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/
>
> but clearly something has gone wrong!!!
>
> Can someone help me to commit?
> Thanks.
>
>

It seems you didn't commit your changes in the local folder, so git 
send-email sent the last commit in your sources.

Here is a generic how-to (probably inefficient as there are likely 
better ways to rebase, but you aren't doing many changes anyway):

1. git clone 
(in a new folder)
2. make your changes
(this is rebasing, LEDE sources have changed since your last download, 
and you must send your commit over the latest sources or it will likely 
fail to merge)
3. git add .
(this will add all changes you did to git tracking)
4. git commit
(it will open the commit text editor, you should write the commit 
title/subject as first line, then leave a blank line, then write the 
commit message, save and close the editor to commit)

5.git send-email -1 --annotate
(this takes the last commit and will also load again a text editor so 
you can edit the mail subject like adding [LEDE-DEV], and check that 
what you are sending is indeed your commit, you can abort by pressing 
Ctrl+C)


I think that git by default uses vim as text editor (or at least does so 
on OpenSUSE), if you don't like vim (like me), you can change that by 
writing

git config --global core.editor "text-editor-name"

where by "text-editor-name" you place nano, or gedit, or whatever is the 
text editor you want.

p.s. once you sent this patch successfully I'm probably going to add 
this quick guide to the wiki.

-Alberto

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

Re: [LEDE-DEV] patch for dwr-512 support

[Alberto Bursi]

On 11/13/2016 06:33 PM, Rafał Miłecki wrote:
> On 13 November 2016 at 17:59, Giuseppe Lippolis  
> wrote:
>> Dear all,
>> I’m sending to the community the following patch to support the dlink
>> dwr-512.
>
> Please use a proper commit message (with target as a prefix) &
> description. Your singed-off-by is required. I also noticed your patch
> is white space mangled, please use some more reliable mailer, so we
> can actually apply your patch.
>

like git send-email

see here:
https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/

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