From: Felix Fietkau
b5d13611d35e mt76: mt7915: fix monitor mode issues
bbbac7deee3d wifi: mt76: rename mt76_packet_id_init/flush to
mt76_wcid_init/cleanup
f1e1e67d97d1 wifi: mt76: fix race condition related to checking tx queue fill
status
b3f739a64e6b wifi: mt76: mt7996: add eht rx rate
From: Felix Fietkau
890ae4d717f1 wifi: mt76: mt76x02: fix MT76x0 external LNA gain handling
fcc2f3d82bc9 wifi: mt76: fix lock dependency problem for wed_lock
77cc14596202 wifi: mt76: mt792x: move mt7921_skb_add_usb_sdio_hdr in mt792x
module
bc85355885d1 wifi: mt76: mt792x: move some common usb
On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote:
>
> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> > It's quite strange that they updated 2.5.0.1 branch first but my
> > understanding that there should be updates for the newer 2.7.0.1 branch
> > as well (2.7.0.1 branch is also in
On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> It's quite strange that they updated 2.5.0.1 branch first but my
> understanding that there should be updates for the newer 2.7.0.1 branch
> as well (2.7.0.1 branch is also in linux-firmware).
Yes, I also told them in the support ticket
Kalle Valo writes:
> + ath11k, jeff
>
> Sven Eckelmann writes:
>
>> On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote:
>> [...]
The Qualcomm bulletin[1] says "Patches are being actively
>>> > shared with OEMs".
>>> >
>>> > Were these bugfixes made available for OpenWRT? Is
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 ---
Branch: refs/heads/master
Hello.
This patch series brings support for ASUS RT-AC3200 and ASUS RT-AC5300 on
OpenWrt.
Note to Rafał, please apply this after backporting the device tree patches
for these devices.
Signed-off-by: Arınç ÜNAL
---
Arınç ÜNAL (2):
bcm53xx: add support for ASUS RT-AC3200 and ASUS RT-AC5300
From: Arınç ÜNAL
Add ASUS RT-AC3200 and ASUS RT-AC5300 to the set wireless LED behaviour
quirk. ASUS RT-AC3200's wireless chip is different than ASUS RT-AC5300's,
the environment variables for it are 0:ledbh10 and 1:ledbh10.
Signed-off-by: Arınç ÜNAL
---
package/utils/nvram/Makefile
From: Arınç ÜNAL
ASUS RT-AC3200 and ASUS RT-AC5300 are AC3200 and AC5300 routers,
respectively, featuring 5 Ethernet ports over the integrated Broadcom
switch.
ASUS RT-AC3200 hardware info:
* Processor: Broadcom BCM4709A0 dual-core @ 1.0 GHz
* Switch: BCM53012 in BCM4709A0
* DDR3 RAM: 256 MB
*
st...@linux-ipv6.be writes:
> phy_write_paged(phydev, 31, 27, 0x0002);
> val = phy_read_paged(phydev, 31, 28);
..
> phy_write_paged(phydev, 0x1f, 0x1b, 0x0002);
> val = phy_read_paged(phydev, 0x1f, 0x1c);
While you're doing spring cleaning That piece of cut-n-paste
Hi Stijn,
On Sat, Apr 27, 2024 at 01:40:07AM +0300, st...@linux-ipv6.be wrote:
> Respect the phy-is-integrated property on ethernet-phy nodes.
>
> There are RTL8393M switches where the PHYs at address 48 and 49 are
> provided by an external RTL8214FC. Hardcoding them to use the internal
> SerDes
According to the Realtek SDK code, the RTL8214FC, RTL8218B and RTL8218FB
all have the same chip ID 0x6276. Let's add a constant for it, as we're
using it in more than one location.
Signed-off-by: Stijn Tintel
---
.../linux/realtek/files-5.15/drivers/net/phy/rtl83xx-phy.c | 6 --
1 file
Respect the phy-is-integrated property on ethernet-phy nodes.
There are RTL8393M switches where the PHYs at address 48 and 49 are
provided by an external RTL8214FC. Hardcoding them to use the internal
SerDes makes it impossible to use the ports connected to such an
external PHY. Respect the
On 2024-04-25 22:12, Linus Walleij wrote:
> These patches have been cooking for some time, let's
> get them moving.
>
> The idea is to merge this base so we have base support
> for the target and then try to work out remaining issues
> such as the LED handling.
>
> To:
>
> Signed-off-by: Linus
This is needed to boot the BCM6238-based Inteno XG6846.
Currently this is restricted to the XG6846 board.
Signed-off-by: Linus Walleij
---
.github/labeler.yml | 1 +
package/boot/uboot-bmips/Makefile | 32
2 files changed, 33 insertions(+)
diff
It appears that the CFE boot loader found in the XG6846
cannot load kernels over a certain size, and the old
relocate hack is not working.
What to do? We can build a small U-Boot into the image,
make CFE boot that, place the kernel immediately after
U-Boot, and use U-Boot to boot the system
Since we split the Inteno XG6846 "firmware" partition with the
uImage MTD splitter, we need to compile in support for this
splitting method into the BCM6328.
Signed-off-by: Linus Walleij
---
target/linux/bmips/bcm6328/config-6.1 | 1 +
1 file changed, 1 insertion(+)
diff --git
This add a device tree and build options for the XG6846
switch/router to the BMIPS target.
Hardware:
- SoC: Broadcom BCM6328
- CPU: BMIPS4350 V7.5
- RAM: 64 MB DDR
- NOR Flash: 16 MB parallel (CFE and OS)
- Ethernet LAN: 4x 1Gbit
- Ethernet WAN: 2x 1Gbit, fiber and TP
- Buttons: reset
-
These patches have been cooking for some time, let's
get them moving.
The idea is to merge this base so we have base support
for the target and then try to work out remaining issues
such as the LED handling.
To:
Signed-off-by: Linus Walleij
---
Changes in v2:
- Include U-Boot for BMIPS patch
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 ---
Hello,
Is it possible 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 ---
Hi there!
Are you interested in
commit 33ec3d52cea628df91eb0eb1701e16172c1e - HEAD
Problems.
the first error was the absence of
/home/user/openwrt/staging_dir/target-mips_24kc_musl/usr/include/libubox/udebug.h
Had to manually download udebug.h from the libubox repo...?
Next error - (c)make cannot seem to find
Hi,
út 23. 4. 2024 v 11:15 odesílatel Ravi Paluri (QUIC)
napsal:
>
> We are seeing same error even on OpenWRT v22.03
> iptables v1.8.7 (legacy): Couldn't load match `u32':No such file or directory
>
> Can you anyone please guide us?
You are combining legacy iptables and nftables. I do not think
We are seeing same error even on OpenWRT v22.03
iptables v1.8.7 (legacy): Couldn't load match `u32':No such file or directory
Can you anyone please guide us?
Thanks,
Ravi
-Original Message-
From: openwrt-devel On Behalf Of Ravi
Paluri (QUIC)
Sent: Tuesday, April 23, 2024 12:35 PM
To:
Hi All,
On OpenWRT v23.05, we have enabled iptables in addition to nftables.
We have a use-case wherein we want to parse first 4 bytes of header (which
holds an integer) and match it with another predefined integer.
For this matching, we are using u32 module and invoking this module via -m
From: Rafał Miłecki
mt7915e driver supports MT7915 & MT7916 devices and MT7981 & MT7986
on-SoC wireless controllers. Devices based on MT7988 and possibly other
next chipsets are quite unlikely to need it (MT7988 was designed to be
used with MT7996).
Move kmod-mt7915e to DEVICE_PACKAGES of
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 ---
Branch: refs/heads/master
From: Rafał Miłecki
It's needed by some drivers, e.g. mt7925, see:
mt7925/mcu.c:2181:23: error: implicit declaration of function
'ieee80211_vif_is_mld' [-Werror=implicit-function-declaration]
Signed-off-by: Rafał Miłecki
---
...-mac80211-warn-only-once-on-AP-probe.patch | 32 ++
From: Rafał Miłecki
It's needed by some drivers, e.g. mt7925, see:
mt7925/main.c:264:9: error: implicit declaration of function
'_ieee80211_set_sband_iftype_data' [-Werror=implicit-function-declaration]
Signed-off-by: Rafał Miłecki
---
...d-ieee80211_set_sband_iftype_data-he.patch | 49
I do not see anyone from the committers complaining about the revert. If
folks felt that a vote was neccesseary, then someone would have started one.
I have a feeling that folks are happy with the old status quo and no
vote is required.
John
On 18.04.24 16:13, Paul D wrote:
On
On 2024-04-16 16:41, Etienne Champetier wrote:
> Le mar. 16 avr. 2024 à 10:34, Paul D a écrit :
>>
>> On 2024-03-27 23:56, Etienne Champetier wrote:
>>>
>>> As this is a legal issue, should we get SFC opinion first ?
>>>
>>> Etienne
>>>
>>
>> Is this happening?
>
> Sorry I missed your last ping
From: Tomasz Maciej Nowak
Dell/SonicWall APL26-0AE (marketed as SonicPoint ACe) is a dual band
wireless access point. End of life as of 2022-07-31.
Specification
SoC: QualcommAtheros QCA9550
RAM: 256 MB DDR2
Flash: 32 MB SPI NOR
WIFI: 2.4 GHz 3T3R integrated
5 GHz 3T3R QCA9890 oversized
Attention Sir/Madam,
I hope this message finds you well. I am writing to inform you of some exciting
news regarding the delivery of your consignment. Diplomat James Morgan, who has
been mandated by our company to ensure the safe and prompt delivery of your
consignment, has just arrived in your
Hi Raylynn,
On 2024/04/11 15:57, Raylynn Knight wrote:
Hiroshi,
I’m late responding also so no problem.
On Apr 8, 2024, at 9:48 PM, INAGAKI Hiroshi wrote:
Hi Raylynn,
sorry for late reply.
From my understanding...
On 2024/04/05 4:42, Raylynn Knight via openwrt-devel wrote:
If I
Le mar. 16 avr. 2024 à 10:34, Paul D a écrit :
>
> On 2024-03-27 23:56, Etienne Champetier wrote:
> >
> > As this is a legal issue, should we get SFC opinion first ?
> >
> > Etienne
> >
>
> Is this happening?
Sorry I missed your last ping
This was an open question, I don't know who to contact at
On 2024-03-27 23:56, Etienne Champetier wrote:
>
> As this is a legal issue, should we get SFC opinion first ?
>
> Etienne
>
Is this happening?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
From: Tomasz Maciej Nowak
Dell/SonicWall APL26-0AE (marketed as SonicPoint ACe) is a dual band
wireless access point. End of life as of 2022-07-31.
Specification
SoC: QualcommAtheros QCA9550
RAM: 256 MB DDR2
Flash: 32 MB SPI NOR
WIFI: 2.4 GHz 3T3R integrated
5 GHz 3T3R QCA9890 oversized
W dniu 15.04.2024 o 14:32, Paul D pisze:
>
>>> 6. Adjust "ipaddr" (access point) and "serverip" (TFTP server) addresses
> Might be an idea to explicitly document these IPs so that dedicated users can
> already set their gear to those IPs and just smash enter
Will add them in v2, but given the
Robert Marko wrote:
> On Mon, 18 Mar 2024 at 06:31, Mathew McBride wrote:
> >
> > Hi all,
> >
> > A change in kernel 6.2 ("gpio: Get rid of ARCH_NR_GPIOS (v2)") [1] resulted
> > in the GPIO chip base numbers changing on some architectures (x86, arm and
> > arm64 were directly modified in that
Hi Jean,
On Wed, 10 Apr 2024 12:25:05 +0200
Jean Thomas wrote:
> Add a dummy prefix in case a name in the upstream JSON files is a
> C reserved keyword.
>
> This is the case with the "Register" element of the new "Configure
> Profile Event List" message.
>
> Signed-off-by: Jean Thomas
On 4/04/2024 19:42, INAGAKI Hiroshi wrote:
Hi stijn,
Hi Hiroshi,
I have some comments below.
Thanks for reviewing!
On 2024/04/04 23:28, st...@linux-ipv6.be wrote:
+
+ reboot@0 {
+ compatible = "edgecore,reboot";
Isn't this a "gpio-restart"? I can't find any informations about
>> 6. Adjust "ipaddr" (access point) and "serverip" (TFTP server) addresses
Might be an idea to explicitly document these IPs so that dedicated users can
already set their gear to those IPs and just smash enter
___
openwrt-devel mailing list
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 ---
Branch: refs/heads/master
Maybe it is possible to deploy the system with secure boot and a
protected IDevId key by default, but allowing the user/owner to erase
the key and disable secure boot? This way all use cases could be
supported, including playing with the BL2 code etc.
(I'm sure all of you have noticed, but I'm
Bjørn Mork wrote:
> Michael Richardson writes:
>> Having orange and red pieces "secured" *does* mean that u-boot updates
would
>> have to come from openwrt.
> Does it? Is it possible to modify the BL2 to verify signatures of the
> BL31 and BL32 stages only?
I don't
Fixing typos to make the whole message clearer.
On Sun, Apr 14, 2024 at 01:03:04AM +0200, Enrico Mioso wrote:
> On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote:
> >
> > Daniel Golle wrote:
> > >> In the first PDF, there is mention of:
> > >> Security Support 2 *
On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote:
>
> Daniel Golle wrote:
> >> In the first PDF, there is mention of:
> >> Security Support 2 * 256-bit multi-key on OTP eFuse
> >> Support 64 version OTP eFuse for anti-rollback
>
> > Those features require
W dniu 13.04.2024 o 16:05, Tomasz Maciej Nowak pisze:
> From: Tomasz Maciej Nowak
>
> Dell/SonicWall APL26-0AE (marketed as SonicPoint ACe) is a dual band
> wireless access point.
>
> Specification
> SoC: QualcommAtheros QCA9550
> RAM: 256 MB DDR2
> Flash: 32 MB SPI NOR
> WIFI: 2.4 GHz 3T3R
From: Tomasz Maciej Nowak
Dell/SonicWall APL26-0AE (marketed as SonicPoint ACe) is a dual band
wireless access point.
Specification
SoC: QualcommAtheros QCA9550
RAM: 256 MB DDR2
Flash: 32 MB SPI NOR
WIFI: 2.4 GHz 3T3R integrated
5 GHz 3T3R QCA9890 oversized Mini PCIe card
Ethernet: 2x
Michael Richardson writes:
> Having orange and red pieces "secured" *does* mean that u-boot updates would
> have to come from openwrt.
Does it? Is it possible to modify the BL2 to verify signatures of the
BL31 and BL32 stages only?
If not, is it feasible to deploy an automated fip.bin signer,
On Fri, Apr 12, 2024 at 11:58:19PM +, Eric wrote:
> On Thursday, April 11th, 2024 at 22:19, Denver Gingerich
> wrote:
>
> > On Fri, Apr 12, 2024 at 06:34:08AM +0200, John Crispin wrote:
> >
> > > On 12.04.24 02:19, David Bauer via openwrt-devel wrote:
> > >
> > > > can you share which
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 Thursday, April 11th, 2024 at
On Fri, Apr 12, 2024 at 05:37:22PM -0400, Michael Richardson wrote:
>
> John Crispin wrote:
> >> using OP-TEE and fTPM.
>
> > pretty high on my list once we find the time
>
> >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html
> >
>
John Crispin wrote:
>> using OP-TEE and fTPM.
> pretty high on my list once we find the time
>
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html
>
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html
Where you
Daniel Golle wrote:
>> In the first PDF, there is mention of:
>> Security Support 2 * 256-bit multi-key on OTP eFuse
>> Support 64 version OTP eFuse for anti-rollback
> Those features require proprietary tools provided by MediaTek only to
> clients under NDA. Unless some
using OP-TEE and fTPM.
pretty high on my list once we find the time
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html
___
On Fri, Apr 12, 2024 at 01:38:01PM -0400, Michael Richardson wrote:
>
> John Crispin wrote:
> > On 12.04.24 15:30, Michael Richardson wrote:
> >> Is the MT7981B specification available publically at this point?
> >>
> >> I can find a 7986 sheet on hackaday, but who knows how it
John Crispin wrote:
> On 12.04.24 15:30, Michael Richardson wrote:
>> Is the MT7981B specification available publically at this point?
>>
>> I can find a 7986 sheet on hackaday, but who knows how it differs
(marketing
>> people and their numbers)
>>
> Hi
>
On 12.04.24 15:30, Michael Richardson wrote:
Is the MT7981B specification available publically at this point?
I can find a 7986 sheet on hackaday, but who knows how it differs (marketing
people and their numbers)
Hi
http://mirror2.openwrt.org/docs/
John
Is the MT7981B specification available publically at this point?
I can find a 7986 sheet on hackaday, but who knows how it differs (marketing
people and their numbers)
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
On Fri, Apr 12, 2024 at 06:34:08AM +0200, John Crispin wrote:
> On 12.04.24 02:19, David Bauer via openwrt-devel wrote:
> > can you share which identifier was assigned for OpenWrt? I don't see it
> > in the list of the
> > IEEE yet.
>
> The process is still pending. SFC needs to register the OUI
On 12.04.24 02:19, David Bauer via openwrt-devel wrote:
can you share which identifier was assigned for OpenWrt? I don't see
it in the list of the
IEEE yet.
The process is still pending. SFC needs to register the OUI block as
"does business as" to make sure OpenWrt shows up as the name.
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 ---
Hi John,
can you share which
> Bjørn Mork wrote: "And I consider immutable source-less compiled binary blobs
> the absolute worst kind of all binary blobs.
> They are impossible to debug and fix, and have exactly no theoretical chance
> of ever been replaced by an open source alternative, even in the wettest
> libre
Hi Ivan,
On Thu, Apr 11, 2024 at 10:15:58AM +, Ivan Ivanov wrote:
> > there are no Wifi-5+ chips on the market that can run without blobs
>
> This is true, but at the same time - undoubtedly - some chips are more
> likely to be liberated from blobs than the others. Some WiFi chip may
> have
On 2024-04-11 10:52, Bjørn Mork wrote:
> Ivan Ivanov writes:
>
>>> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C
>>
>> Are these Mediateks capable of working without any binary blobs, at
>> least in theory?
>
> A simple question back to you: Could you please list the wifi chips you
> know of
Ivan Ivanov writes:
> BootROM is considered by Free Software Foundation as a part of
> hardware
And I consider immutable source-less compiled binary blobs the absolute
worst kind of all binary blobs. They are impossible to debug and fix,
and have exactly no theoretical chance of ever been
> there are no Wifi-5+ chips on the market that can run without blobs
This is true, but at the same time - undoubtedly - some chips are more
likely to be liberated from blobs than the others. Some WiFi chip may
have been partially researched (i.e. someone tried to reverse-engineer
its binary
Hi,
On 11.04.2024 10:52, Bjørn Mork wrote:
Ivan Ivanov writes:
SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C
Are these Mediateks capable of working without any binary blobs, at
least in theory?
A simple question back to you: Could you please list the wifi chips you
know of which ether
Ivan Ivanov writes:
>> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C
>
> Are these Mediateks capable of working without any binary blobs, at
> least in theory?
A simple question back to you: Could you please list the wifi chips you
know of which ether have
a) completely open source firmware,
On 11.04.24 10:15, Ivan Ivanov wrote:
SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C
Are these Mediateks capable of working without any binary blobs, at
least in theory? (i.e. some existent reverse-engineering research)
If not, why have they been chosen in particular? IMHO the "OpenWRT
One"
> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C
Are these Mediateks capable of working without any binary blobs, at
least in theory? (i.e. some existent reverse-engineering research)
If not, why have they been chosen in particular? IMHO the "OpenWRT
One" project hardware should not be worse
> My 2 cent on the problem of permitting nick is that if we accept that,
> some funny guy might use nickname like "ExtraHardCockSucker"
> and we wouldn't have anything to say about it and have to accept
> it if the contribution is correct.
An immature person who uses such a nickname - is quite
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 ---
Hiroshi,
I’m late responding
> It's not beautiful, but it works:
>
> xargs -a blacklist.txt -I {} sh -c 'find package \( -name "$1" -prune \) -o
> -type f -print' sh {}
>
>
I take that back - no it doesn't :/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
On 2024-04-10 16:45, Philip Prindeville wrote:
>
>
>> On Apr 9, 2024, at 6:03 PM, Paul D wrote:
>>
>> On 2024-04-09 23:30, Philip Prindeville via openwrt-devel wrote:
>>> I'm trying to modify a script generates a list of filenames one per
>>> line, but should be filtered against a blacklist of
Hi
We will auction off one or two OpenWrt One.
The first 15 EVT samples have been tested, and a new production run of
100 DVT samples will start shortly. these 100 samples will have OpenWrt
OUI macs and calibration data. the winners of the auction will receive
samples via express courier
Hi,
We will auction off one or two OpenWrt One.
The first 15 samples have been tested, an
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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 Apr 9, 2024, at 6:03 PM,
Signed-off-by: Jean Thomas
---
commands-nas.c | 46 +-
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index d791fee..d06934f 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -97,6 +97,33 @@
* Add 5G NR to supported networks in DMS --get-capabilities.
* Add 5G NR to supported mode in NAS --set-network-modes.
* Add 5G NR signal information to NAS --get-signal-info.
* Add 5G NR system information to NAS --get-system-info.
* Add 5G NR to supported radios in NAS --get-tx-rx-info.
* Add 5G
Add a "radio_interface" array to the NAS --get-serving-system
command.
Signed-off-by: Jean Thomas
---
commands-nas.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/commands-nas.c b/commands-nas.c
index d06934f..8865fc4 100644
--- a/commands-nas.c
+++
Add a dummy prefix in case a name in the upstream JSON files is a
C reserved keyword.
This is the case with the "Register" element of the new "Configure
Profile Event List" message.
Signed-off-by: Jean Thomas
---
data/gen-common.pm | 52 +-
1 file
Hello everyone!
We're doing an OpenWrt summit this year. We're inviting all OpenWrt
enthusiasts to join us at the event. We will auction off one or two OpenWrt
One. And we will have a big cake for OpenWrt's 20 year anniversary. It's
going to be a relaxed event full of social activities with
Michael Richardson writes:
> Bjørn Mork wrote:
>
> > I assume the private key must be protected on the device. What are the
> > hardware requirements?
>
> There are no hard and fast rules. It certainly would be best if it's in some
> enclave. But, my take is that something is better
From: Paul Donald
Now DNSSL Option 31 inherit the search list from an 'interface' also.
( A behaviour described in LuCI, but did not seem to exist before ).
ICMPv6 Option (DNS Search List Option lan lalala)
Type: DNS Search List Option (31)
Length: 4 (32 bytes)
Reserved
From: Paul Donald
Applies to master d8118f6e76e5519881f9a37137c3a06b3cb60fd2
Na??ve implementation. Works well.
Might have drawbacks: it parses interfaces, so if they happen to have the same
parameter names, ???
The idea seems worth implementing.
Paul Donald (1):
config: use network
On 2024-03-27 23:56, Etienne Champetier wrote:
>
>
> (On my phone, Gmail mobile only sends html emails, sorry for that)
>
> As this is a legal issue, should we get SFC opinion first ?
>
> Etienne
>
When can we know the result of such an opinion?
On 2024-04-09 23:30, Philip Prindeville via openwrt-devel wrote:
> I'm trying to modify a script generates a list of filenames one per
> line, but should be filtered against a blacklist of file globs.
>
> Something like:
>
> % find dir -print | grep -v -f blacklist
I got this. When I run it
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 Tuesday, April 9th, 2024 at
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 ---
Sent with Proton Mail secure
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 ---
Hi,
I'm trying to modify a
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 ---
Hi,
I'm trying to modify a
Source code is your friend...
My two cents are on the backport of the HAS_LUAJIT_ARCH dependency to snort3.
Main/master shows that symbol definition:
```
.config - OpenWrt Configuration
> Search (LUAJIT)
Hi Eric,
On Tue, 9 Apr 2024 at 18:59, Eric via openwrt-devel
wrote:
>
> 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 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 Tuesday, April 9th, 2024 at
Hi Eric,
út 9. 4. 2024 v 19:00 odesílatel Eric via openwrt-devel
napsal:
>
> 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
>
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 ---
I noticed this before, but never
On certain types of links, i.e. active ethernet fiber links,
we can have both fixed speed and autonegotiation on at the
same time. It is, in these cases, not speed which is being auto-
negotiatied but the use of pause frames.
This fix reverts back to the old behaviour before switching
to the new
Defaults to off.
Only available from >= 1.0.15
These capabilities are sent in TLV.
Signed-off-by: Paul Donald
---
package/network/services/lldpd/files/lldpd.init | 7 +++
1 file changed, 7 insertions(+)
diff --git a/package/network/services/lldpd/files/lldpd.init
201 - 300 of 61347 matches
Mail list logo
