Philip Prindeville [2021-05-17 16:43:24]:
> I could grovel the target profile out of /etc/board.json, but then my
> scripting needs to support 'jq', etc.
$ ubus call system board | jsonfilter -e @.model -e @.board_name
-- ynezz
___
openwrt-devel mai
Okay, I've created a PR to make this change:
https://github.com/openwrt/openwrt/pull/4184
> On May 17, 2021, at 4:43 PM, Philip Prindeville
> wrote:
>
> Hi,
>
> I was wondering what the best way to map a running box back to a candidate
> image would be.
>
> It seems like the tuple ($CONFI
This fixes `iw dev wlan0-mesh station dump`.
8fab0c9 iw: fix ftm_request missing arguments segfault
e816fbc iw: fix mgmt dump missing arguments segfault
5d9d1b8 iw: Fix timestamp output on 32-bit architectures
4b25ae3 iw: fix pointer arithmetic in __print_he_capa
c3df363 iw: add option to print hu
Hi,
I was wondering what the best way to map a running box back to a candidate
image would be.
It seems like the tuple ($CONFIG_TARGET_BOARD, $CONFIG_TARGET_SUBTARGET,
$CONFIG_TARGET_PROFILE) would provide this, since you can mangle them into a
bin/targets/$CONFIG_TARGET_BOARD/$CONFIG_TARGET_S
May 17, 2021 21:53:01 Hauke Mehrtens :
On 5/17/21 8:10 PM, Paul Spooren wrote:
On 5/16/21 3:57 PM, Hauke Mehrtens wrote:
On 5/16/21 3:26 PM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the OpenW
Hi,
On 17-05-21, Paul Spooren wrote:
> Hello,
>
> after some back and forth I'd like to request some more opinions on what
> kind of Docker containers to offer containing the OpenWrt rootfs. This is
> not about the SDK or ImageBuilder Docker containers.
>
> tl;dr:
>
> Should we ship `slim` cont
Hello
Certainly run /sbin/init or 'procd' to have *OpenWrt-like experience* is
a better approach in my view.
Regards
Fernando
On 17/05/2021 15:39, Paul Spooren wrote:
Hello,
after some back and forth I'd like to request some more opinions on
what kind of Docker containers to offer contain
Hi,
> >
> > What's in 0x200 to 0x214? Or did I miscalculate?
>
> No, no miscalculation. This was taken from factory.
>
> But please wait, I'm working on an alternative!
If this stays empty please just add a brief comment about that fact into the
DTS.
> > That's a very unusual location
On 5/17/21 8:10 PM, Paul Spooren wrote:
On 5/16/21 3:57 PM, Hauke Mehrtens wrote:
On 5/16/21 3:26 PM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the OpenWrt 21.02
feeds.
If one of the other key
Hello,
after some back and forth I'd like to request some more opinions on what
kind of Docker containers to offer containing the OpenWrt rootfs. This
is not about the SDK or ImageBuilder Docker containers.
tl;dr:
Should we ship `slim` containers only, running a OpenWrt shell (ash) and
noth
On 4/19/21 11:16 PM, Paul Spooren wrote:
On 4/19/21 9:45 AM, Hauke Mehrtens wrote:
Since OpenWrt 21.02 we use https for our download server, detect these
URLs too.
Signed-off-by: Hauke Mehrtens
---
Can't you kick out anything lede-project related while at it?
I will have a look at the scri
On Mon, 17 May 2021 at 20:08, Paul Spooren wrote:
>
>
> On 5/16/21 6:01 PM, Robert Marko wrote:
> > Update ethtool to newly released 5.12 version.
> >
> > Signed-off-by: Robert Marko
> > ---
> Could this be moved to packages.git?
Yes, I think that someone even posted a patch some time ago for th
On 5/16/21 6:01 PM, Robert Marko wrote:
Update ethtool to newly released 5.12 version.
Signed-off-by: Robert Marko
---
Could this be moved to packages.git?
package/network/utils/ethtool/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/utils
On 5/16/21 3:55 PM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the OpenWrt 19.07
feeds and the 21.02 feeds to allow checking the next release.
If one of the other keys would be compromised this wo
On 17.05.2021 17:32, Paul Oranje wrote:
Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende
geschreven:
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward compatibility add a tempor
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Op 17 mei 2021, om 16:49 heeft Raf
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Op 17 mei 2021, om 16:49 heeft Raf
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward compatibility add a temporary config translation.
Config example:
config device
option name 'lan'
option type 'bridge'
Seems good to me.
The main question is: most home users will require it ? I don't think
so. But there may be others that may do, so as long http does not
forward to https seems a good approach so those who want can
deliberately use https.
I think as it stands now forcing https only would be a
When trying to build an image for the Layerscape "NXP LS1046A-RDB SD
Card Boot" target using Image Builder, you get the following error
messages:
...
Package list missing or not up-to-date, generating it.
Building package i
From: Rafał Miłecki
UCI "interface" L3 sections use "ifname" option for pointing L2 devices.
A more accurate option would be "device" but for now adjust UI at least
to make configuration easier for LuCI users.
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/view/network/inter
From: Rafał Miłecki
netifd has been recently patched to use more accurate "ports" option
instead of "ifname"
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/tools/network.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/modules/luci-mod-
Hi!
Am 17.05.21 um 12:54 schrieb Bjørn Mork:
> Andre Valentin writes:
>
>> There are gaps between the partitions. I can only imagine that this is
>> because of bad block handling in the bootloader.
>> It seems it uses the end of the flash for reserve and also has holes betwee
>> partitions for
Andre Valentin writes:
> There are gaps between the partitions. I can only imagine that this is
> because of bad block handling in the bootloader.
> It seems it uses the end of the flash for reserve and also has holes betwee
> partitions for this.
Yes, that makes sense.
> Manufacturer implem
This adds a new device id to the image tools.
Signed-off-by: André Valentin
---
tools/firmware-utils/src/zytrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/firmware-utils/src/zytrx.c b/tools/firmware-utils/src/zytrx.c
index 302efc6010..b3bbbe3c69 100644
--- a/tools/firmware-utils/
Add mkfs.ubifs tool as package. It may used in the sysupgrade process.
Signed-off-by: André Valentin
---
package/utils/mtd-utils/Makefile | 17 +
1 file changed, 17 insertions(+)
diff --git a/package/utils/mtd-utils/Makefile b/package/utils/mtd-utils/Makefile
index 5a4b03da96..4
mtdsplit_squashfs always splits into rootfs and rootfs_data. Wit this
patch is not possible to give the new partition a different name.
Example:
partition@14 {
reg = <0x14 0x1ea>;
compatible = "openwrt,uimage", "denx,uimage", "openwrt,squashfs";
label = "firmwar
The ZyXEL LTE3301-Plus is an 4G indoor CPE with 2 external LTE antennas.
Specifications:
- SoC: MediaTek MT7621AT
- RAM: 256 MB
- Flash: 128 MB MB NAND (MX30LF1G18AC)
- WiFi: MediaTek MT7615E
- Switch: 4 LAN ports (Gigabit)
- LTE: Quectel EG506 connected by USB3 to SoC
- SIM: 1 micro-SIM s
This set adds support for the ZyXEL LTE3301-Plus, an indoor 3G/4G indoor LTE
router with Wifi.
André Valentin (4):
firmware-utils: zytrx: Add support for ZyXEL LTE3301-Plus
mtdsplit-squashfs: allow devicetree to define the name of the new
partition
package/mtdutils: add ubifs-tools packa
Andre Valentin writes:
>>> diff --git a/target/linux/ramips/mt7621/base-
>>> files/etc/board.d/03_gpio_switches b/target/linux/ramips/mt7621/base-
>>> files/etc/board.d/03_gpio_switches
>>> index ed728b07c4..1959d8c9d2 100644
>>> --- a/target/linux/ramips/mt7621/base-files/etc/board.d/03_gpio_swi
Hi !
Am 15.05.21 um 18:08 schrieb Bjørn Mork:
> [ answering some comments which also apply to the NR7101 ]
>
> "Adrian Schmutzler" writes:
>
>>> + partition@14 {
>>> + label = "Kernel";
>>> + reg = <0x14 0x1ec>;
>>> + };
>>
>>
Andre Valentin writes:
> Am 15.05.21 um 12:00 schrieb Bjørn Mork:
>
>> But I winder if my initial implementation was a bit on the stupid
>> side. We might want to move those two fields out of the code and just
>> provide them directly as input parameters instead of this indirect
>> mapping. What
Hi Adrian!
Please see comments below!
Am 15.05.21 um 16:05 schrieb Adrian Schmutzler:
> Hi,
>
> comments below.
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of André Valentin
>> Sent: Samstag, 15. Mai 2021 02:12
>> To: open
From: Rafał Miłecki
The old way of defining bridge (L2) as part of interface (L3) is
deprecated. All such configs should be migrated to define bridge as L3
UCI section type "device".
Signed-off-by: Rafał Miłecki
---
.../luci-static/resources/tools/network.js| 388 +++---
.../re
Am 15.05.21 um 12:00 schrieb Bjørn Mork:
> André Valentin writes:
>
>> This adds a new device id to the image tools.
>>
>> Signed-off-by: André Valentin
>> ---
>> tools/firmware-utils/src/zytrx.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/firmware-utils/src/zytrx.c
>> b/
Hi,
There have been reports of 5.4 kernel crash on ipq806x related to cpufreq:
https://bugs.openwrt.org/index.php?do=details&task_id=3099
As far as I can tell, you changed the cpufreq driver recently (more
recently than the bug reports):
6e411b8416388 ("ipq806x: backport cpufreq changes to
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On 2021-05-16 23:57, Hauke Mehrte
It might happen that driver returns a huge scan results e.g.
when there are many access points available in the area where
scanning is performed. Currently, all scan results are copied
to the buffer, no matter the buffer size.
This adds a guard to prevent buffer overflow i.e. scan buffer can
be fil
38 matches
Mail list logo