* Eric Schultz [23.02.2017 07:57]:
> prpl member IntrinsicID has physically unclonable function technology which
> allows a key to be generated at bootup based upon the physical
> characteristics of the device. It's the same key generated everytime but it
this is not
* Michael Richardson [23.02.2017 07:57]:
> Yes, use an asymmetric key, and distribute the public part only.
thanks people, for all the input and your ideas. our approach
is now this: we hook into the 'usign' sourcecode and "hide" a
secret there: 2 large random primenumbers. On
According to LEDE's source code:
config KERNEL_CRASHLOG
bool "Crash logging"
depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64)
default y
https://github.com/lede-project/source/blob/master/config/Config-kernel.in
It is enabled by default on some targets and will be
This also fixes FS#544 as the allocation causing possible address alignment
issue should now disappear
Size comparison on x86_64 system
function old new delta
alloc_module 398 245
Hi,
Has anyone managed to use kdump with OpenWRT/LEDE?
I have a box which periodically panics, and since /var is a link to /tmp/ there
are no persistent logs. Which reminds me: is it safe to configure a third
partition on my CF card, format it as ext3, and mount that as /var/log in
Hi,
I've been using old version of OpenWRT and umount -f works just fine.
But some time ago it was lost.
Does anyone know point where I could shorten check for remote accessibility?
Thank you all.
On Thu, Feb 23, 2017 at 12:08 AM, Florian Fainelli wrote:
>
>
> On
On 02/22/2017 08:48 AM, Denis Periša wrote:
> Hi all,
>
> I'm having this problem long from long time ago.
> When NFS server is not responding which is currently case for me (and
> my log files go there) I cannot unmount network volume even with -f
> (force). Actually I think that -f don't do
Hello Jo,
yes, your commit fixes this issue.
Thank you very match.
Regards,
Hartmut
Am 22.02.2017 um 13:50 schrieb Jo-Philipp Wich:
> Hi Hartmut,
>
> I believe this issue is fixed with https://git.lede-project.org/19720a6 now.
>
> ~ Jo
>
___
Bastian,
prpl member IntrinsicID has physically unclonable function technology
which allows a key to be generated at bootup based upon the physical
characteristics of the device. It's the same key generated everytime but
it isn't actually stored in flash. Their technology requires a paid
license
To all who devoted so much effort into rolling out LEDE 17.01.0...
This has been a monumental project, requiring thousands of updates, bug fixes,
and serious re-designing of so many parts of the code base and build machinery.
I also thank those who worked to create the supporting
Bastian Bittorf wrote:
> There are "automated" signatures (e.g. from builbot) and manual ones,
> from humans. For protecting ourselfes from bad admins, there should be
> a "secret thing" which is baked into the firmware and only seeable
> during runtime: this way we
Hi,
The LEDE Community is proud to announce the first stable version of the
LEDE 17.01 version series.
LEDE 17.01.0 "Reboot" incorporates thousands of commits over the last
nine months of effort. With this release, the LEDE development team
closes out an intense effort to modernize many parts of
Thanks, the image work on my TP-Link TL-WA854RE v1
is it possible that you contact the lede project to integrade you modifcations
that i included in the next version ?
thanks
Gesendet: Mittwoch, 22. Februar 2017 um 01:43 Uhr
Von: Ufo
An:
Hi all,
I'm having this problem long from long time ago.
When NFS server is not responding which is currently case for me (and
my log files go there) I cannot unmount network volume even with -f
(force). Actually I think that -f don't do any change to unmount.
I was kinda hoping in LEDE it will
Add new dt-bindings precompiler include to replace numerical default
VLAN assignments with more meaningful descriptive values, such that
0x3f -> VLAN_CONFIG_L
0x2f -> VLAN_CONFIG_W
0x3e -> VLAN_CONFIG_W
In that we we get the best of both worlds: the usability of having
strings and all
On Wed, Feb 22, 2017 at 04:33:00PM +0100, Stefan Koch wrote:
> 1) So one possibility is to disable CONFIG_MIPS_MT_SMP when the vmmc driver
> package is selected. But this conflicts with Default Target approach which
> builds images for all xrx200 based devices.
> 2) Create a menu entry within
On Wed, 2017-02-22 at 16:33 +0100, Stefan Koch wrote:
>
> *IMPORTANT*
> To use VPE at least CONFIG_MIPS_MT_SMP needs to be disabled within
> xrx200/config-default and nosmp added to the kernel command line
> Without nosmp within command line the full SMP part must be disabled
>
> *WARNING*
> If
On 2017-02-22 15:36, Daniel Golle wrote:
> Just like on Rt305x, use numerical values for portmap instead of
> strings. Map strings in device-tree definitions to numerical values
> such that:
> "w" = <0x2f>
> "w" = <0x3e>
> "l" = <0x3f>
>
> Signed-off-by: Daniel Golle
Just like on Rt305x, use numerical values for portmap instead of
strings. Map strings in device-tree definitions to numerical values
such that:
"w" = <0x2f>
"w" = <0x3e>
"l" = <0x3f>
Signed-off-by: Daniel Golle
---
Apply only after switch to kernel 4.9!
* Yousong Zhou [22.02.2017 13:19]:
> How about generating at build time a piece of c code whose output when
> run at the target board will be the source code itself (quine). We
> can use the output content to seed the computation of signature. The
> binary itself should
Hi Hartmut,
I believe this issue is fixed with https://git.lede-project.org/19720a6 now.
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On 22 February 2017 at 17:05, Bastian Bittorf wrote:
> There are "automated" signatures (e.g. from builbot) and manual ones,
> from humans. For protecting ourselfes from bad admins, there
> should be a "secret thing" which is baked into the firmware and
> only seeable during runtime:
On Wed, Feb 22, 2017 at 1:36 PM, Felix Fietkau wrote:
> On 2017-02-21 23:10, Sergey Ryazanov wrote:
>> Hello,
>>
>> I tried to install latest LEDE to RB411AH board. Sysupgrade worked
>> fine, but device now do not boot at all. Bootloader claims that it
>> could not find kernel :(
On 2017-02-21 23:10, Sergey Ryazanov wrote:
> Hello,
>
> I tried to install latest LEDE to RB411AH board. Sysupgrade worked
> fine, but device now do not boot at all. Bootloader claims that it
> could not find kernel :(
>
> I tracked down the situation and found that the kernel partition image
>
On 2017-02-22 11:21, Sergey Ryazanov wrote:
> Ok. Could we discuss your NACK? Don't you like YAFFS just because it
> is a non-upstream code or you do not like YAFFS as a file system?
Because it's a very large chunk of non-upstream code.
> In first case I would like to note that this code is
On Wed, Feb 22, 2017 at 11:41 AM, Felix Fietkau wrote:
> On 2017-02-21 23:10, Sergey Ryazanov wrote:
>> Hello,
>>
>> I tried to install latest LEDE to RB411AH board. Sysupgrade worked
>> fine, but device now do not boot at all. Bootloader claims that it
>> could not find kernel :(
* Joris de Vries [22.02.2017 10:34]:
> Still it is a very interesting idea and I’d love to read more thoughts on
> this!
i will give a talk about this on battlemesh/vienna.
I the slides are ready, i will poke the list...
bye, bastian
This is a fascinating idea, although I think conceptually it is similar to DRM
where in the end it is impossible to avoid giving the user the keys needed to
decrypt content. In your scenario, I cannot see a way to avoid a rogue admin
gaining access to the runtime-secret (but that certainly does
dear devs,
I'm polishing up our work-in-progress regarding automated
firmware-upgrades in our community network and I have a concept problem:
our images/the sha256-sum's are signed:
On 2017-02-22 07:55, Alive 4ever wrote:
> I am currently working on adding support for LEDE build system to
> generate UEFI bootable images.
>
> What I've done in this WIP:
> [*] Adding grub2-efi-amd64 and grub2-efi-ia32 packages.
> [*] Adding new targets under x86: 64-efi and efi, which can be
On 2017-02-21 23:10, Sergey Ryazanov wrote:
> Hello,
>
> I tried to install latest LEDE to RB411AH board. Sysupgrade worked
> fine, but device now do not boot at all. Bootloader claims that it
> could not find kernel :(
>
> I tracked down the situation and found that the kernel partition image
>
love it!
+1 for last.
On Tue, Feb 21, 2017 at 11:10 PM, Sergey Ryazanov
wrote:
> Hello,
>
> I tried to install latest LEDE to RB411AH board. Sysupgrade worked
> fine, but device now do not boot at all. Bootloader claims that it
> could not find kernel :(
>
> I tracked
32 matches
Mail list logo