On 04/17/2012 11:15 AM, Mirko Vogt wrote:
Hey Emmanuel,
I levelled up all versions of eglibc to i's latest revisions of its
respective branches ( https://dev.openwrt.org/changeset/31300 ) and
therewith I guess broke eglibc version 2.12 which I'd like to purge out
anyway. Is there any reason for
On 04/19/2012 05:41 AM, Mirko Vogt wrote:
I also noticed complains about glibc - however every time I ask people
why in particular they chose glibc over eglibc I didn't get any
meaningful response. glibc is de facto unmaintained in OpenWrt and I'd
actually like to purge it out - still I'm
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and unless I've missed some very recent patch, we're still sans
full support of all the LEDs on the AG300N. Anyone want to
On 07/27/2012 07:35 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/07/28, at 8:04, Peter Naulls wrote:
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and unless
On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote:
Peter and folks,
I believe Peter meant WZR-HP-AG300H.
Last night, I did some research on behaviors of leds on WZR-HP-AG300H,
and located controls for all remaining leds on wmacs.
Awesome, seems to work fine. Thanks.
On 07/31/2012 11:45 PM, LEO Airwarosu Yoichi Shinoda wrote:
The problem of wmac based leds on WZR-HP-AG300H stimulated
some research on status of led support on other buffalo
units with wmac based leds.
The following results and observations are based on the
trunk revision r32910.
COMMON
-
On 08/01/2012 09:03 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/08/01, at 22:39, Peter Naulls wrote:
The problem here is that the LED handling is done in the wrong
order. I submitted a fix/patch(?) for this months ago, but
it seems to have been ignored or lost. I can dig it out
again
This is not strictly on topic for this list, so I'll keep this pretty short.
I'm after a developer to work in the Bay Area on OpenWrt stuff. You should
be a junior/mid level developer willing to learn new skills but who knows
the basics of embedded development. We do lots of other stuff, but
On 02/11/2013 12:04 PM, Aleksander Morgado wrote:
Hey,
I'm trying to prepare an update of udev/libudev to latest upstream. As
you may already know, udev/libudev sources are now within systemd. I'm
not fully sure how to handle this issue; so I'm hoping to get some
advice here. Comments welcome!
I've been bugging a lot of people about this, with hopes to get my patches in,
so I apologize to those long-suffering on IRC.
The quick version:
glibc 2.13 (with my patches) works and I have tested it extensively (within the
confines of my work) on a71xx, ramips and kirkwood. None of the old
Is anyone else seeing lockups on WZR-HP-G300NH flash?
I have an sqlite3 database that I am accessing, but it causes the file system to
eventually get stuck. This is typically for example a find /overlay
stopping before getting to the file in question, and requiring a ctrl-C.
On reboot, there
On 08/13/2011 02:45 PM, Peter Naulls wrote:
So, I don't have much to go on. Suggestions on how to resolve
this welcome.
From echo t /proc/sysrq-trigger
(functions copied manually from System.map, sorry for any errors)
rsync R running 0 2760 2759 0x0010
Stack
On 08/13/2011 05:31 PM, Peter Naulls wrote:
On 08/13/2011 02:45 PM, Peter Naulls wrote:
So, I don't have much to go on. Suggestions on how to resolve
this welcome.
From echo t /proc/sysrq-trigger
(functions copied manually from System.map, sorry for any errors)
And from a second run
On 08/13/2011 06:57 PM, Peter Naulls wrote:
On 08/13/2011 05:31 PM, Peter Naulls wrote:
On 08/13/2011 02:45 PM, Peter Naulls wrote:
So, I don't have much to go on. Suggestions on how to resolve
this welcome.
From echo t /proc/sysrq-trigger
This appears to be a recurrence of an old
This adds the o11s cozybit authentication daemon fork of authsae (see o11s.org).
This requires forthcoming work on o11s in the
kernel/compat-wireless et al. but there are people interested in running
this under OpenWrt right now.
I have not added any init scripts, etc.
Signed-off-by: Peter
On 08/16/2011 02:28 PM, Felix Fietkau wrote:
On 2011-08-16 11:51 AM, Mark Deneen wrote:
Please let me know if there is anything which I have overlooked.
Looks mostly fine to me on a first quick look (aside from some whitespace vs tab
issues).
Before we accept this, I want to split out the
On 08/30/2011 06:57 AM, Mark Deneen wrote:
On Tue, Aug 30, 2011 at 1:34 AM, LEO Airwarosu Yoichi Shinoda
shin...@jaist.ac.jp wrote:
On 2011/08/30, at 6:13, Peter Naulls wrote:
I have an immediate need to support v1 and v2 hardware in one image. As
products they are essentially identical
On 09/09/2011 08:42 AM, Manuel Munz wrote:
Hi
this patch fixes 3 things in the imagebuilder, one of them is literally big:
When running package_install the imagebuilder generates package list(s),
which are stored in $(TARGET_DIR)/usr/lib/opkg/lists/ and then copied
into the final image, which
On 09/09/2011 10:02 AM, Manuel Munz wrote:
But why is CLEAN_IPKG not
selected by default? And can we have a backport of this to backfire?
Why should it be? If you want it on, select it. It's the same option
from menuconfig.
Thats not an option for me. I build the most generic profile and
Some of this is speculation. I wish I had more precise details. This is true
of all trunk versions in last few weeks, when I started using my G300H (v2)
as an AP. This includes upto version r28254, which includes yesterday's
mac80211 patches, but not today's spam fixes.
I have two Linux
On 09/16/2011 11:26 AM, Peter Naulls wrote:
* In one case where I saw it triggered, I restarted hostapd, and it seemed to
come back, although NetworkManager on Ubuntu become confused, so I'm
not certain.
* There is nothing of consequence in kernel logs, apart from regular messages
from
On 09/16/2011 12:53 PM, Jim Henderson wrote:
On Fri, 16 Sep 2011 15:08:15 -0400, Mark Deneen wrote:
In the end, I ended up reverting to build 27572, which I knew worked
prior to the upgrade.
I reverted the mac80211 package only to 27572 earlier today, and it seems to now
be working
On 09/17/2011 12:28 AM, Felix Fietkau wrote:
On 2011-09-17 8:50 AM, Felix Fietkau wrote:
On 2011-09-17 1:54 AM, Peter Naulls wrote:
On 09/16/2011 12:53 PM, Jim Henderson wrote:
On Fri, 16 Sep 2011 15:08:15 -0400, Mark Deneen wrote:
In the end, I ended up reverting to build 27572, which I
These are taken from the Debian PHP patches. Thanks to jow and mhei for
suggestions. I tested this with my eglibc setup/zoneinfo files.
I think the comments in the patches describe the intent here.
Signed-off-by: Peter Naulls pe...@chocky.org
Index: patches/102
mount.cifs, or other words, the cifs kernel modules requires a number of pieces
which are missing from its dependency. I spent a lot of time chasing
this, and don't have the energy to chase it all up and make dependency
patches etc, however if someone else does, I can say that it requires the
On 11/08/2011 02:15 PM, Michael Geddes wrote:
Hi,
The x86 build of Kontron compiles.. as I said, the 64bit endeavour was
abandoned. A couple of years ago it compiled, but didn't really work. The
reason it's still there is because I thought it might be useful for somebody
to continue what I
On 11/09/2011 08:42 AM, Mirko Vogt wrote:
On 11/09/2011 01:20 AM, Peter Naulls wrote:
On 11/08/2011 02:15 PM, Michael Geddes wrote:
I don't know about the target hardware in question or the 64-bit builds,
but for any hope of having glibc/eglibc builds work
Building with eglibc should work
On 11/10/2011 05:59 AM, Ben Pfountz wrote:
I would like to see support in trunk as well. In the meantime I have been using
the patch Mark Deneen created, which adds support for everything except some of
the LEDs and switches, see his email and thread for more info...
On 11/10/2011 08:13 AM, Mark Deneen wrote:
On Thu, Nov 10, 2011 at 9:42 AM, Peter Naullspe...@chocky.org wrote:
On 11/10/2011 05:59 AM, Ben Pfountz wrote:
I would like to see support in trunk as well. In the meantime I have been
using
the patch Mark Deneen created, which adds support for
On 11/10/2011 08:21 AM, Peter Naulls wrote:
I'll test any such patches of course. As an additional note, we're
going to need the same thing on a300gh, since I'm getting one of those
in next few days. I'll submit any work on that here, even if it's
Now done. It's a mess right now, so
On 11/17/2011 12:37 AM, Matt Redfearn wrote:
That's great Peter, any ideas when you would be able to get the patches into
trunk?
Did you read my previous posts? Probably never. The developers have
expressed a desire to not combine images. Why? I remain unsure.
There's an argument to be
-HP-G300NH2 board support
+ * Buffalo WZR-HP-AG300H board support
*
* Copyright (C) 2010 Gabor Juhos juh...@openwrt.org
+ * Copyright (C) 2011 Felix Fietkau n...@openwrt.org
+ * Copyright (C) 2011 Mark Deneen mden...@gmail.com
+ * Copyright (C) 2011 Peter Naulls pe...@chocky.org
...@openwrt.org
+ * Copyright (C) 2011 Felix Fietkau n...@openwrt.org
+ * Copyright (C) 2011 Mark Deneen mden...@gmail.com
+ * Copyright (C) 2011 Peter Naulls pe...@chocky.org
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public
BuildPackage,linux-zigbee-$(x
Signed-off-by: Peter Naulls pe...@chocky.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 12/16/2011 09:45 AM, Jo-Philipp Wich wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I didn't make this patch, it came from jow. I changed use of libnl-tiny
to libnl, since in my testing, it didn't compile with the former.
What are the issues with libnl-tiny? I really don't
On 12/28/2011 11:09 AM, Victor Khimenko wrote:
[Try and retain attributions if you can]
For anyone who's not been following, this means that
WZR-HP-G300NH, WZR-HP-G300NH2 and WZR-HP-AG300N are
supported in a single image.
How is it supposed to work? I've just spent about six
Without wanting to engage in a debate about what LEDs should do at any
given time, and knowing for certain that my own requirements are special
here, as well probably needing to maintain my own modifications here,
can someone give me a summary of the current LED mappings are on these
3 Buffalo
On 01/04/2012 08:55 AM, Jo-Philipp Wich wrote:
Hi.
Error: bad register name `%sil'
You probably need a patch similar to this:
http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/binBCldaQtw31.bin
Apart from that, there are still a number of pending patches required for
I'm trying to use kexec as a fallback/flash mechanism. But something is going
wrong:
http://pastebin.com/0uvNnMQd
So the device halts after/during the serial port setup, and returns to boot
loader. Anyone want to suggest what might be going wrong, or where to
start looking?
On 01/05/2012 09:43 AM, Florian Fainelli wrote:
Hello,
You should enable kernel debugging in your kexec'd kernel and see whether the
serial port is being left with IRQs disabled from the original kernel.
I turned on kernel debug, but I'm unsure what exactly I'm looking at.
It may be that
On 01/06/2012 07:06 AM, Paolo Pisati wrote:
On 01/06/2012 11:48 AM, Florian Fainelli wrote:
Then this might be an entirely different issue. Try to run the kexec'd
kernel uncached and see if that helps (there is a MIPS-specific Kconfig
option to do that).
but is kexec working at all on MIPS
On 01/06/2012 02:48 AM, Florian Fainelli wrote:
Then this might be an entirely different issue. Try to run the kexec'd kernel
uncached and see if that helps (there is a MIPS-specific Kconfig option to do
that).
CONFIG_MIPS_L1_CACHE_SHIFT=5 ? There's other related stuff in
arch/mips/Kconfig
On 01/06/2012 08:10 AM, Peter Naulls wrote:
As an alternative, I'm looking at first jumping to an ar71xx version
of u-boot (as per OpenWrt build), all I should need to add to that
is flash support for the G300NH(2). Perhaps that puts the system
in more consistent state before starting Linux
On 01/07/2012 03:25 AM, Florian Fainelli wrote:
Le samedi 07 janvier 2012 00:32:31, Peter Naulls a écrit :
On 01/06/2012 08:10 AM, Peter Naulls wrote:
As an alternative, I'm looking at first jumping to an ar71xx version
of u-boot (as per OpenWrt build), all I should need to add
For comedy value, I enabled preemption in my G300NH build:
124.49] BUG: scheduling while atomic: swconfig/811/0x0002
[ 124.50] 2 locks held by swconfig/811:
[ 124.50] #0: (genl_mutex){+.+...}, at: [8021cd20] genl_rcv+0x14/0x34
[ 124.51] #1:
On 01/12/2012 02:26 AM, Florian Fainelli wrote:
Hello Peter,
The system seemed otherwise ok, but I didn't test beyond this.
Can you describe how you run into this error? Just so that we can reproduce and
fix the problem.
Should have provided more details. I had to rebuild the kernel to
I think this is the same kernel I've been using a long time on
WZR-HP-G300NH, (that is, not the preemptive options I
mentioned yesterday), but I did recently turn on debugging.
I think this may help explain some occasional flash failures
we've been seeing (this is the only one with a serial
I'm seeing this:
Realtek RTL8366S ethernet switch driver version 0.2.2
[1.01] rtl8366s rtl8366s: using GPIO pins 19 (SDA) and 20 (SCK)
[1.01] rtl8366s rtl8366s: unknown chip id ()
[1.02] rtl8366s rtl8366s: chip detection failed, err=-19
[1.03] eth0: Atheros
On 01/11/2012 07:16 PM, Mark Deneen wrote:
Quick question, since I don't know the full story here.. but the
buffalo gpl source for u-boot for the G300NH is available. The NH2
u-boot source is MIA, though.
http://opensource.buffalo.jp/gpl_wireless.html
It's in the G300NH tarball. The source
On 01/16/2012 01:49 PM, jonsm...@gmail.com wrote:
I can't get any of the glibc versions to build on ARM. I wanted to use
glibc as a way of eliminating ulibc as the source of the bug. They all
fail with various compile errors.
Less than 2.7 complains about binutils.
cue weekly response
2.7 is
Add support for the Rainforest Automation Zigbee dongle.
This is against 2.6.39 only, however Linux 3.2 does not have this
ID either.
Signed-of-by: Peter Naulls pe...@chocky.org
Index: target/linux/generic/patches-2.6.39/823-usb_serial_ftdi_add_more_devices.patch
On the G300NH (v1), the router LED is turned on at boot completion
to indicate it's running. Or at least, that's the intent of the
done script. But the led script which sets up the mappings has
START=96, but the done script is 95. So it never gets turned on.
I fixed that in my setup by
On 01/25/2012 02:50 PM, Philip Prindeville wrote:
I'm told that my patches languish because they are for 2.6.39.4 (or
whatever)
and I'm encouraged to go to a newer kernel... but I can't because all of the
churn with the ath9k goes untested and tends to be extremely destabilizing to
the ath5k
On 02/06/2012 08:52 AM, jonsm...@gmail.com wrote:
Most ARM CPUs have boot ROMs for getting the initial image out of
flash. I'm referring to the boot loader that loads uboot, not uboot.
The ARM CPUs I've worked with search for a signature in flash, if they
can't find a valid signature they load
Hi guys, I mention in case anyone is interested. I've started work on
an OpenWrt port to the Bulogics gateway. I've documented here:
http://wiki.openwrt.org/toh/bulogics/smartgrid
I'm actually a bit beyond that, have found serial port, etc, etc. I
think the software/kernel itself is pretty
On 02/25/2012 07:13 AM, Bastian Bittorf wrote:
Remembering the old days, where we had floppy-drives?
Now we have MTD. sad but true, in case of any error during
sysupgrade regarding mtd, there are no further checks
and we are f*cked:
###
Performing system upgrade...
Unlocking linux ...
Writing
On 02/25/2012 10:15 AM, Bastian Bittorf wrote:
cause is, but what I have seen is that the mtd utility
needs to retry sometimes, and that [e] condition
is a temporary Out of memory error. At least, on ar71xx.
out of memory doesnt satisfy me.
And? I'm telling you what the error is at this
On 10/18/22 15:55, Martin Blumenstingl wrote:
Hello Peter,
On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote:
Looks like there was some code loss when the driver came from an earlier kernel
series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
number, I don't know
Looks like there was some code loss when the driver came from an earlier kernel
series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
number, I don't know):
--- a/drivers/gpio/gpio-mt7621.c2022-10-18 15:03:42.596454871 -0400
+++ b/drivers/gpio/gpio-mt7621.c
On 10/18/22 17:10, Lukas Zeller wrote:
.
Just not any more - the mt7621 had this too. I currently patch it back into
22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3]
I can follow the rationale to get rid of legacy GPIOs, but in the context
of experimenting platforms, where
Yes, I know. Bear with me. Laugh if you must.
# ls -l /rom/
...
drwxr-xr-x4 root root98 Oct 20 13:53 www
I'd like to remove the writable bits from the squashfs image - /www is
particular concern because of security paranoia.
Now I realize that:
1. This is contrary to
Apologies for the obtuseness of the previous email about the squashfs
permissions - that's related to the following, but a different topic. I can now
say that we're undergoing a security review for our system which is very much
based upon OpenWrt 22.03.
If you have ever done this, you'll
On 10/19/22 05:51, Lukas Zeller wrote:
Hi,
Lukas, thanks for this. I've read through everything and I agree with your
concerns. I'll note also that Linus W's commentary is from 2018.
On 19 Oct 2022, at 08:55, Petr Štetiar wrote:
IMO there should be `ugpiod` daemon available over ubus,
This is of course from ca-certificates 20211016
$ openssl x509 -enddate -noout -in
build_dir/target-mipsel_24kc_musl/root-ramips/etc/ssl/certs/Cybertrust_Global_Root.crt
notAfter=Dec 15 08:00:00 2021 GMT
$ openssl x509 -enddate -noout -in
On 10/24/22 18:21, Hauke Mehrtens wrote:
Hauke, thanks for replying!
I also prefer if the CVE number is named in the patch. If this is missing
somewhere you could send a patch or pull request to rename the patch.
I'm afraid I don't have any explicit examples, but I'll let you know if
find
The default uhttpd configuration has this:
# HTTP listen addresses, multiple allowed
list listen_http0.0.0.0:80
list listen_http[::]:80
Now, I know there's lots of practical reasons for this to be the case,
and I know also that the firewall setup in OpenWrt is
On 10/23/22 23:35, Phillip Lougher wrote:
On Thu, Oct 20, 2022 at 6:01 PM Peter Naulls wrote:
What you probably want is the following
% mksquashfs test test.sqsh -action "chmod(ugo-w)@perm(/ugo+w)"
It is, fantastic, thank you.
I added to include/image.mk:
--- a/include/imag
On 10/25/22 20:45, Reuben Dowle wrote:
My opinion is that openwrt should try and move to a newer version of lua. This
old 5.1.5 version appears to be unmaintained, and there does not seem to be the
resources within the openwrt community to change that.
So I naively adjusted the lua5.3
On 10/25/22 18:20, openwrt-devel-requ...@lists.openwrt.org wrote:
From: Nathan Lutchansky
My hands are tied, we gotta do the dance.
I mean this as gently as possible, but I think what a lot of us are
missing is the benefit to the OpenWrt project to carry an increased
maintenance burden in
On 10/25/22 17:25, Reuben Dowle wrote:
I have myself gone through the process of getting an openwrt based product
through a security audit.
The issue of HTTP listening on all interfaces also came up in my audit, but the
auditors were happy with the explanation that the firewall prevented
On 10/25/22 17:45, Michael Richardson wrote:
So, it needs to bound to *all* the IPv6 "LAN" IPs.
That means:
a) the ULA that is created.
b) the LL-IPv6 that are always present
c) the GUA IPv6 that is delegated
Sorry, I badly paraphrased. The requested change was for IPv4 only. I
Lua 5.1.5 would appear to have CVEs below against it.
The patches to this in OpenWrt are significant, but dated, with the
last bug fix seeming to be from 2019, so it's hard to say if
these are addressed:
https://github.com/openwrt/openwrt/tree/openwrt-22.03/package/utils/lua/patches
On 10/25/22 16:40, Karl Palsson wrote:
Peter Naulls wrote:
If they see what they want to see, then why should anyone else
get involved in their wish fulfilment?
Security review is fine, security should not be entertained, and
certainly foisted on other people?
Karl, not sure where you're
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote:
is much easier to let the firewall zones deal with that.
As aside, they don't see the iptables tool in the system, and don't
understand that that's been deprecated (although I since did add it
for some unrelated legacy usage), and think
I don't know if this is intentional, or some side effect of my build setup, but
the OpenWrt 22.03 libstdc++ library has some build strings in it.
$ strings
build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/libstdc++.so.6.0.29 | grep
home
...
Some background. I have two versions of OpenWrt code:
One is legacy version based upon a mismash of versions, but is approximately
luci code from mid-2021. The webserver is http only. I'm able to change this
code for bug fixes, but don't want to pull in anything too large.
The other is
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred). The two
cookies could co-exist.
Yes,
On 12/22/22 15:56, Peter Naulls wrote:
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred
I see this warning in Firefox (OpenWrt 22.03):
Loading mixed (insecure) display content
“http://192.168.113.1/luci-static/resources/icons/loading.gif?0.046104145623280135”
on a secure page
This happens when the sysupgrade dialog is processing on an https luci. It
doesn't cause any real
On 12/30/22 15:42, Jo-Philipp Wich wrote:
Hi,
[...]
I renamed the new cookies to "http-sysauth" and "https-sysauth", to work
around this and it seems to do the right thing. But there is still a fault
here.
Already fixed with
In 22.03, px5-mbedtls isn't bothering to check if the output was opened:
--- a/package/utils/px5g-mbedtls/px5g-mbedtls.c
+++ b/package/utils/px5g-mbedtls/px5g-mbedtls.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,11 @@ static void
I've been experimenting with making the overlay encrypted as part of our
security requirements.
There are a couple of things needed to make this work - first, cryptsetup and
other kernel modules need to be brought in. This also needs the upstream kernel
patch to block2mtd that I posted last
On 11/17/22 14:33, Petr Štetiar wrote:
Daniel Golle [2022-11-17 17:01:43]:
Hi,
Add swig/host to build dependencies.
this doesn't looks like a cleanup as commit subject suggests, but rather
contrary :-)
Thanks all in any case for looking at this. We have a possible need to modify
our
Our vendor has put calibration data into flash for the onboard WiFi. They've
made some changes which I have to their supplied 4.14.131 driver to read from
the "factory" flash partition to read calibration data.
As per my previous post on u-boot, getting exact details out of them
has proved
This backports the upstream label feature in block2mtd to the 5.10.x kernel in
22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
--- a/drivers/mtd/devices/block2mtd.c 2022-11-29 07:35:32.382695321 -0500
+++ b/drivers/mtd/devices/block2mtd.c 2022-11-29
On 11/29/22 10:32, Daniel Golle wrote:
On Tue, Nov 29, 2022 at 10:23:48AM -0500, Peter Naulls wrote:
This backports the upstream label feature in block2mtd to the 5.10.x kernel
in 22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
Where are we using
On 11/29/22 11:50, Daniel Golle wrote:
There is nothing wrong with that use-case, and it can even be
interesting for other downstream users. Encrypted rootfs_data is
generally a good idea, especially when rootfs_data is used to store
private key material (think: VPN keys) or other kind of
On 11/29/22 12:37, Daniel Golle wrote:
I thought you are on a device with actual block storage.
For your case I also can't come up with anything better which works
out-of-the-box for NOR flash. Supporting fscrypt in JFFS2 would be more
elegant, but that's a bit more demanding than just using
I needed to add this in my build:
diff --git a/package/boot/uboot-mediatek/Makefile
b/package/boot/uboot-mediatek/Makefile
index 9d823ec698..ac8e5dd0f3 100644
--- a/package/boot/uboot-mediatek/Makefile
+++ b/package/boot/uboot-mediatek/Makefile
@@ -3,7 +3,7 @@ include
as debug.
Signed-off-by: Peter Naulls
---
--- a/src/odhcpd.c 2023-01-24 13:29:56.080616097 -0500
+++ b/src/odhcpd.c 2023-01-24 13:30:19.284692423 -0500
@@ -207,7 +207,7 @@
ssize_t sent = sendmsg(socket, , MSG_DONTWAIT);
if (sent < 0)
- syslog(LOG_ERR, "Failed to send to %s%%%
On 1/24/23 14:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all targets, so we may be able to
release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We
are using GCC 12 as our default compiler version[2]. Binutils has been updated
to version 2.40. Could
I posted previously on GPIOs, which caused some debate; this may or may not
be relevant, but I'd be remiss to not mention it:
http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html
I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt
5.10.161 etc
This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I
brought the config over from my 22.03 build:
CONFIG_GCC_VERSION="11.3.0"
CONFIG_BINUTILS_VERSION_2_38=y
configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely
-mips32r2 -mtune=24kc
.
Signed-off-by: Peter Naulls
diff --git a/target/linux/ramips/dts/mt7621_atel-ei.dts b/target/linux/ramips/dts/mt7621_atel-ei.dts
new file mode 100755
index 00..2dcbd7b932
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_atel-ei.dts
@@ -0,0 +1,177 @@
+/dts-v1/;
+
+#include "mt7621
On 1/22/23 13:58, Daniel Santos wrote:
[snip]
Thanks Daniel and all the others (to many to mention). Yes, I should have read
the datasheet much earlier, so in the end I really have only myself to blame.
The fix was simply to add back in the "rgmii2" group back into the gpio group.
I
https://nvd.nist.gov/vuln/detail/CVE-2021-46848
Against openwrt-22.03
--- /dev/null
+++ b/libs/libtasn1/patches/099-CVE-2020-15888.patch
@@ -0,0 +1,11 @@
+--- a/lib/int.h2022-11-03 10:15:01.065656767 -0400
b/lib/int.h2022-11-03 10:15:39.333658083 -0400
+@@ -97,7 +97,7 @@
The 2.4.9 version of expat in OpenWrt 22.03 contains the following CVEs:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43680
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40674
Suggest either update to 2.5.0 (as per master) or application of the upstream
patches, etc:
On 11/3/22 12:01, Etienne Champetier wrote:
Hi Peter,
Can you resend this as a proper patch ready to be applied ?
Or as a PR on Github if this is easier for you ?
Sorry, retry. I wasn't 100% sure of the filename setup for submitted
patches. I've got a couple more to come.
As per:
On 11/3/22 14:49, Peter Naulls wrote:
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
calling
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
calling 'mbedtls_ecp_check_pub_priv'
I'm not
1 - 100 of 128 matches
Mail list logo
