SC-V (rv64imafdc)":
root@OpenWrt:/# cat /proc/cpuinfo
processor : 0
hart: 0
isa : rv64imafdc
mmu : sv48
mvendorid : 0x31e
marchid : 0x80008a45
mimpid : 0x820
Signed-off-by: Yu Chien Peter Lin
---
system.c | 6 ++
On 5/31/23 21:08, Yousong Zhou wrote:
Not that I got any clue, but this looks very suspicious that you saw
the supposed-to-go-through-tunnel packet at an intermediate router
(the openwrt device).
I don't know exactly what happened here, but I didn't see it again.
In any case, it turns out th
On 5/31/23 10:20, Peter Naulls wrote:
On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls wrote:
Thanks for you patience, more:
I ran the connection instead over a wired WAN connection instead of the cell
WWAN link, and the problem is the same. This points
On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls wrote:
Is it that your dns traffic is not going through the tunnel? curl
-vvv should reveal the IP address it tries to connect. One
possibility is that maybe the resolv result does not work.
Yes, a DNS
On 5/30/23 18:16, Yousong Zhou wrote:
On Wednesday, 31 May 2023, Peter Naulls wrote:
]
I am afraid the above is still single direction traffic.
Sorry, quite so. I finished this email in the middle of something else. There
is return traffic:
To Google, which works.
16:57:11.936911
I'm trying to track down a problem whereby using Windows VPN, some websites are
accessible and some aren't. The problem is 100% OpenWrt, since it works over
my regular WiFi router.
Here's what I know (or think I know):
All the VPN traffic uses UDP port 4500. This is (or should be) a pretty
On 5/7/23 13:19, Hauke Mehrtens wrote:
I check from time to time which companies in the US are looking for OpenWrt
experts [0] to get an overview who is using it. About 10% to 30% of these job
offers require clearance. It looks like the US military and US intelligence
community is using Open
On 5/2/23 09:31, Enrico Mioso wrote:
On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote:
On 5/2/23 07:26, Enrico Mioso wrote:
Another impression I have, is that the OpenWrt project is very important for
many yet under-resourced.
There are some important tasks that would help
On 5/2/23 07:26, Enrico Mioso wrote:
On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote:
On 5/1/23 16:42, Dave Taht wrote:
one of the constraints OpenWrt has been placed under, historically, is the need
to fit in small flash memoris, so fitting some libraries and infrastructure
On 5/1/23 16:42, Dave Taht wrote:
How a ragtag bunch of unincorporated (mostly?) peacenik hippie types
can co-exist with devices being built by militaries out of this stuff
I have few ideas. I prefer to shrink the world, and produce stable,
secure, software, for everyone that wants it, but I lo
For those of you who track the small but very real OpenWrt job market, you may
have seen there's a creep into Defense/Clearance jobs. Here's but one example:
https://careers-bluehalo.icims.com/jobs/3844/job
As a self-declared pacifist (and anyway, dual citizen which would limit my
ability to
On 2/21/23 11:02, Peter Naulls wrote:
On 2/15/23 10:17, Chuanhong Guo wrote:
Hi!
What to try next, thanks!
It looks like the detected spare size and ECC strength matches between the
two drivers, according to the u-boot message and kernel log.
Maybe you can try dumping the nand controller
q->complete = &complete;
| ~~^~~
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- apply pragma ignored only for gcc >= 12.x (as the warning
'-Wdangling-pointer' was introduced with gcc-12.x)
---
dev.c | 12
1 file changed, 12 insertion
q->complete = &complete;
| ~~^~~
Signed-off-by: Peter Seiderer
---
dev.c | 12
1 file changed, 12 insertions(+)
diff --git a/dev.c b/dev.c
index bd10207..b8ac273 100644
--- a/dev.c
+++ b/dev.c
@@ -203,6 +203,15 @@ void qmi_request_cancel(struct qmi_dev
On 2/28/23 09:07, Felix Baumann wrote:
one issue I see here is that there are MT7621 devices like the Asus RT-AX53U
that don't save their environment to their u-boot-env partition by default.
You still need to execute saveenv while connected via serial.
Note: the device doesn't have a u-boot-en
On 2/28/23 06:46, Bjørn Mork wrote:
Peter Naulls writes:
On 2/27/23 17:23, Hauke Mehrtens wrote:
This will add uboot-envtools to all devices. uboot-envtools is not
included in all DEVICE_PACKAGES now, should we explicitly remove it
from device definitions which do not had it before?
The
On 2/27/23 17:23, Hauke Mehrtens wrote:
Build firmware images for Ralink MT7621 based boards.
This will add uboot-envtools to all devices. uboot-envtools is not included in
all DEVICE_PACKAGES now, should we explicitly remove it from device definitions
which do not had it before?
The D
On 2/20/23 09:48, Peter Naulls wrote:
On 2/16/23 17:17, Alexander Papazoglou wrote:
My first guess would be that your microcontroller code doesn't handle repeated
starts properly. All of the i2ctransfer commands you've shown involve at least
one repeated start with the new driver b
On 2/23/23 01:43, Rafał Miłecki wrote:
On 22.02.2023 21:02, Peter Naulls wrote:
config device
option 'lan1'
This line is clearly wrong. See how you specify device name in above section.
Perhaps it is "clear" but there's much in OpenWrt that isn'
On 2/22/23 15:34, Robert Marko wrote:
option 'lan1'
option macaddr 34:BA:9A:CC:DD:EE
This should work as long as its in single quotes.
I corrected the quotes, but no joy.
Also, cant you fixup the MAC in 02_networking or in preinit?
Yes, I have a preinit script, but it
Due to some missing flash values, I need to do a later user space lookup for
possible missing values stored "elsewhere" to fix up the MAC address.
According to:
https://openwrt.org/docs/guide-user/base-system/basic-networking
Something like this should work:
config device
option n
On 2/15/23 10:17, Chuanhong Guo wrote:
Hi!
What to try next, thanks!
It looks like the detected spare size and ECC strength matches between the
two drivers, according to the u-boot message and kernel log.
Maybe you can try dumping the nand controller setup registers and compare
the registe
On 2/16/23 17:17, Alexander Papazoglou wrote:
My first guess would be that your microcontroller code doesn't handle repeated
starts properly. All of the i2ctransfer commands you've shown involve at least
one repeated start with the new driver but perhaps not with the old one. To
verify, you ca
On 2/16/23 13:59, Jan Breuer wrote:
On 16. 2. 2023 16:21, Peter Naulls wrote:
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
Can you please provide info about the exact SoC and hardware you are using?
H
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
In particular, for the first read attempt, the value is always the first
value sent as part of the last write. i.e, 3 in this case. After, that,
it's always 0 (t
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
In my vendor kernel:
[2.243263] i2c-mt7621 1e000900.i2c: clock 100KHz, re-start not support
Which is this driver:
* drivers/i2c/busses/i2c-mt7621.c
*
* Copyright (C) 2013 Steven Liu
* Copyright (C) 2016 Micha
On 2/13/23 15:01, Peter Naulls wrote:
ich might be the misreporting.
In our driver, it comes out as:
[ 16.091826] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB
size: 128
[ 16.107083] mt7621-nand 1e003000.nand: ECC strength adjusted to 12 bits
I tried adjusting in
On 2/11/23 08:10, Chuanhong Guo wrote:
Hi!
# nanddump -a /dev/mtd2
ECC failed: 8
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 128
Dumping data starting at 0x and ending at 0x0004...
libmtd: error!: MEMGETBADBLOCK ioc
On 2/10/23 22:41, Chuanhong Guo wrote:
Hi!
16.163318] 8 fixed-partitions partitions found on MTD device mt7621-nand
From the datasheet here:
https://www.mxic.com.tw/Lists/Datasheet/Attachments/8858/MX30LF1G28AD,%203V,%201Gb,%20v1.3.pdf
The MX30LF1G28AD actually have 2K+128 flash layout, so i
This is the boot on the vendor legacy code - OpenWrt 18.06ish, with kernel
4.14.131, with probably a bunch of their customizations, but:
[9.398860] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28
[9.412077] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[9.42
On 2/7/23 18:35, Eric Montellese wrote:
Hello all,
As I'm sure those on this list are aware, OpenWrt is used extensively in the
commercial router world.
That would be an understatement, we do for one.
At NETGEAR, I am working to find a satisfactory solution to an annoying little
corporate
get right first.
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/;
+
+#inclu
mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float
-mips16 -minterlink-mips16
-fmacro-prefix-map=/home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/elfutils-0.188=elfutils-0.188
-Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong
-D_FORTIFY_SOURCE=1 -W
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 w
ed
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, MSG_DONTWAIT);
if (sent < 0)
- syslog(LOG_ERR, "Failed to send
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 beli
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 ker
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
https://github.com/jow-/lucihttp/commit/6e68a1065f3ed1889e5fa053b
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 har
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, th
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 bas
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 we
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 write_fil
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 wh
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 crede
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
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 08:0
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 tric
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 vendo
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 $(INCLUDE_DIR)/kernel.mk
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:
ht
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
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 p
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
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 @@
+
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 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 packa
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
https://
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
don'
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 a
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&#x
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 there'
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 r
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 a
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
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
... /gcc-11.2.0/libstdc++-v3/src/c++11/debug.cc
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
build_dir/target-mipsel_24kc_musl/root-ramips/etc/s
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 pro
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 th
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, prob
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 G
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
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.c202
uloop_signal_wake(void)
} while (1);
}
-static void uloop_handle_sigint(int signo)
+void uloop_handle_sigint(int signo)
{
uloop_status = signo;
uloop_cancelled = true;
diff --git a/uloop.h b/uloop.h
index 36084f5..ab061a5 100644
--- a/uloop.h
+++ b/uloop.h
@@ -112,4 +112,7 @@ static inlin
, i486
musl: arm, mips
Fixes: FS#4194, FS#4195
Signed-off-by: Peter Lundkvist
---
make_syscall_h.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/make_syscall_h.sh b/make_syscall_h.sh
index 18d9131..17e3bc4 100755
--- a/make_syscall_h.sh
+++ b/make_syscall_h.sh
Hello Petr,
On Sun, 7 Mar 2021 11:27:11 +0100, Petr Štetiar wrote:
> Peter Seiderer [2021-03-06 11:54:49]:
>
> Hi,
>
> thanks a lot for your nice contribution!
>
> > My shell/bash seems to emit a more detailed failure message than
> > expected. Fix this by
Hello Petr,
On Sun, 7 Mar 2021 11:30:28 +0100, Petr Štetiar wrote:
> Peter Seiderer [2021-03-06 11:54:50]:
>
> Hi,
>
> nice, just a small nitpicks, these seems fine:
>
> > + int8_max: 127
> > + int8_min: -128
>
> ...
>
> but the outputs bell
* add mixed int/double tests
* add blobmsg_cast_u64/blobmsg_cast_s64 tests
Signed-off-by: Peter Seiderer
---
tests/cram/test_blobmsg_types.t | 82 +++
tests/test-blobmsg-types.c | 371
2 files changed, 453 insertions(+)
create mode 100644 tests/cram
38.22 sec
--
Test Failed.
"cram" end time: Mar 06 11:37 CET
"cram" time elapsed: 00:00:38
--
[...]
My shell/bash seems to emit a more detailed failure me
_BOOL: 7
BLOBMSG_CAST_INT64: 8
Fix this by changing the enum defintion to assign BLOBMSG_CAST_INT64 to
the unique value 9.
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- re-send after subscribing to the mailing list
- change patch subject prefix from blobmsg to libubox
---
blobms
From: Peter Cardoe
ipq806x: Fix gmac1 (WAN) on Netgear D7800
The WAN port on Netgear D7800 is unable to connect to an ISP when the
link to the modem is running at less than 1GB.
This patch fixes the issue by removing the phy-handle definition
and replacing it with a fixed-link definition
From: Peter Cardoe
Signed-off-by: Peter Cardoe
---
target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-d7800.dts | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-d7800.dts
b/target/linux/ipq806x/files
From: Peter Cardoe
Signed-off-by: Peter Cardoe
---
.../ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-d7800.dts | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-d7800.dts
b/target/linux/ipq806x
Original Message
Subject: PATCH for FS#3086 - Netgear D7800 eth0 WAN Port not working with
100Mbit
From:"Peter Cardoe"
Date:Sun, October 18, 2020 9:51 pm
To: openwrt-devel-ow...@lists.o
:=+apkg` (if there are two providers for `apkg`).
All the best,
Peter
Signed-off-by: Peter Stadler
---
libopkg/pkg_hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
index 52c64ff..f564b6f 100644
--- a/libopkg/pkg_hash.c
+++ b/libopkg
Sorry, this is the wrong patch. Please ignore it.
On 16.07.20 16:28, Peter Stadler wrote:
Set `priorized_matching` to the latest provider with maximum priority, such
that it is similar to the other selections (especially `good_pkg_by_name`).
So, we have consistency between using `opkg install
`).
Signed-off-by: Peter Stadler
---
libopkg/pkg_hash.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
index 52c64ff..9b22f01 100644
--- a/libopkg/pkg_hash.c
+++ b/libopkg/pkg_hash.c
@@ -410,10 +410,15 @@ pkg_t
Removing the line should be good :-)
Beside the error message that `commit` is not found, I experienced no
other issue.
Thank you
Peter
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo
: Peter Stadler
---
libopkg/opkg_remove.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libopkg/opkg_remove.c b/libopkg/opkg_remove.c
index 96ca558..a9c7d5a 100644
--- a/libopkg/opkg_remove.c
+++ b/libopkg/opkg_remove.c
@@ -355,6 +355,12 @@ void remove_data_files_and_list(pkg_t * pkg
Or 'uci_commit network' …
On 27.03.20 13:36, Peter Stadler wrote:
prepend 'uci' to 'commit network'
Signed-off-by: Peter Stadler
---
.../netifd/files/etc/uci-defaults/14_migrate-dhcp-release | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
prepend 'uci' to 'commit network'
Signed-off-by: Peter Stadler
---
.../netifd/files/etc/uci-defaults/14_migrate-dhcp-release | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/package/network/config/netifd/files/etc/uci-defaults/14_migrate-dhcp-releas
on selection of best candidate
Signed-off-by: Peter Stadler
---
libopkg/pkg.h | 4 +++-
libopkg/pkg_depends.c | 27 ++-
libopkg/pkg_hash.c| 8
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/libopkg/pkg.h b/libopkg/pkg.h
index 600fc9e
Additionally it would be good to ignore conflicting packages, when
selecting a provider in `pkg_hash_fetch_best_installation_candidate`.
Please look at the extended patch:
Signed-off-by: Peter Stadler
---
libopkg/pkg.h | 3 ++-
libopkg/pkg_depends.c | 25
Do not install a package if another package that is already installed
lists the new package (or one of its providees) as conflicting.
Without checking for reverse conflicts, the conflicting packages need
cyclic conflicts, which are not supported by `make menuconfig`.
Signed-off-by: Peter Stadler
-functions
without removing the constness. You could pass them to `blobmsg_data`,
but the getters would be the cleaner way as their name is more verbose
(and they handle the format).
So, it is (should be) more a cosmetic change that reflects the usage.
Peter
P.S.: I am also happy if the
blobmsg_data.
Signed-off-by: Peter Stadler
---
blobmsg.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/blobmsg.h b/blobmsg.h
index be3c7ee..a76bc87 100644
--- a/blobmsg.h
+++ b/blobmsg.h
@@ -260,27 +260,27 @@ static inline int blobmsg_buf_init(struct blob_buf
On Mon, Jan 27, 2020 at 4:00 PM Piotr Dymacz wrote:
>
> Hi Peter,
>
> On 27.01.2020 19:57, Peter Geis wrote:
> > On Mon, Jan 27, 2020 at 1:35 PM Adrian Schmutzler
> > wrote:
> >>
> >> Just a quick one:
> >>
> >> > > So, no matte
On Mon, Jan 27, 2020 at 1:35 PM Adrian Schmutzler
wrote:
>
> Just a quick one:
>
> > > So, no matter what we do, there is no easy way forward.
> >
> > We could remove all ar71xx -> ath79 migration helper scripts, ar71xx
> > board names from supported devices lists in ath79 images and make the
> >
On Wed, Jan 15, 2020 at 6:01 PM Hauke Mehrtens wrote:
>
> Hi,
>
> I meet with jow about 2 weeks ago and we talked about a lot of OpenWrt
> related stuff, one of the topics was the release after 19.07.
>
> As the 19.07 release is now done, I would like to follow up on this topic.
>
> We thought tha
1 - 100 of 474 matches
Mail list logo
