Applause, applause.
The first (partial) docs of the magic of sysupgrade. And its pitfalls.
Having had various issues with sysupgrade myself in the past (also doing
sysupgrade OTA), I add following notes:
- Having open files on storage devices (i.e. for swap, but also explicitly
opened) broke s
I've been investigating a problem with sysupgrade failing with the error
message "Failed to kill all processes", and then hanging indefinitely.
This happens maybe once every 10-20 sysupgrades, and it's kind of a pain.
So far I've determined this workflow that the sysupgrade command follows.
Note,
From: Philip Prindeville
Make sure no buffer overruns present a vulnerability in the firewall.
Get rid of unsafe string functions: strcpy, strncpy, strcat, strncat,
sprintf, etc. Doing pointer arithemetic with the return value of
sprintf() is inherently unsound. Per the sprintf() man page:
On Wed, 13 May 2020 at 00:39, Philip Prindeville
wrote:
>
>
>
> > On May 12, 2020, at 7:08 AM, Yousong Zhou wrote:
> >
> > On Sat, 2 May 2020 at 03:21, Philip Prindeville
> > wrote:
> >>
> >> From: Philip Prindeville
> >>
> >> If the start_time > stop_time on a rule, then the --contiguous arg
>
Hi!
After hours of bisecting which change between hostapd_2_8 and
hostapd_2_9 broke SAE in mesh mode with WolfSSL we got a result:
> commit 6c9543fcb7962e26c2a91c43089abe171d073b44
> Author: Jouni Malinen
> Date: Thu Apr 25 20:18:27 2019 +0300
>
> Share common SAE and EAP-pwd functionality: r
On 5/12/20 12:24 PM, Bjørn Mork wrote:
> Hauke Mehrtens writes:
>
>> I also get this problem with mainline kernel.
>>
>> See here for some more details:
>> https://bugs.openwrt.org/index.php?do=details&task_id=2928
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506
>
> Hello,
>
> I wondered
That’s presumably what the kmod-mt76x2 is for…
> On May 12, 2020, at 7:44 AM, Enrico Mioso wrote:
>
> Out of curiosity, is MT7602 supported?
>
> thanks!!
> Enrico
>
>
> On Tue, 12 May 2020, Stijn Segers wrote:
>
>> Date: Tue, 12 May 2020 14:53:15
>> From: Stijn Segers
>> To: openwrt-devel@
Op dinsdag 12 mei 2020 om 15u44 schreef Enrico Mioso
:
Out of curiosity, is MT7602 supported?
thanks!!
Enrico
It is and has been for a while. 2,4 GHz on MT7621 (especially the older
2,4 GHz radios) isn't the best though.
Cheers
Stijn
On Tue, 12 May 2020, Stijn Segers wrote:
Date:
> On May 12, 2020, at 7:08 AM, Yousong Zhou wrote:
>
> On Sat, 2 May 2020 at 03:21, Philip Prindeville
> wrote:
>>
>> From: Philip Prindeville
>>
>> If the start_time > stop_time on a rule, then the --contiguous arg
>> should be included in the rule.
>
> It seems that start_time >= stop_ti
Paul Fertser [2020-05-11 17:43:56]:
Hi,
> On Mon, May 11, 2020 at 04:25:42PM +0200, Petr Štetiar wrote:
> > > If we execute `wg --version` we get a diffrent version string that does
> > > not match with the version string in the openwrt makefile.
> > >
> > > Current version string:
> > > `wiregu
On Mon, May 11, 2020 at 06:56:53PM -0500, Alex Ballmer wrote:
> Hi there,
>
> I am trying to get a quectel RM500Q modem working using modemmanager
> 1.12.10 on openwrt 18.06.2. Since the device I am on uses a 4.14
> kernel, I manually backported the following changes from linux upstream
> to allow
Out of curiosity, is MT7602 supported?
thanks!!
Enrico
On Tue, 12 May 2020, Stijn Segers wrote:
Date: Tue, 12 May 2020 14:53:15
From: Stijn Segers
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] mt7621: add kmod-mt7603 to DIR-860L B1
DEVICE_PACKAGES
Op dinsdag
On Sat, 2 May 2020 at 03:21, Philip Prindeville
wrote:
>
> From: Philip Prindeville
>
> If the start_time > stop_time on a rule, then the --contiguous arg
> should be included in the rule.
It seems that start_time >= stop_time has its defined meaning in
xt_time module. Better add another uci op
Op dinsdag 12 mei 2020 om 12u05 schreef Stijn Segers
:
The DIR-860L B1 has an MT7603 radio but was missing the corresponding
kmod-mt7603 module in DEVICE_PACKAGES.
Add this so it gets included by default, even when the kmod gets set
to [m].
Nevermind me... This device has an MT7602 radio
Is this a patch you'd like to send upstream to
wiregu...@lists.zx2c4.com?
Yes this would be the fix for the version problem in Openwrt.
This would be nice if this gets applied into the wireguard repository.
___
openwrt-devel mailing list
openwrt-devel@
Is this a patch you'd like to send upstream to wiregu...@lists.zx2c4.com?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hello Paul
Thank you for your thoughts.
ok, but I fail to see why this patch should be maintained by OpenWrt,
this
looks like it should be fixed upstream. Thanks.
I think this is not possible every project does have his own rules.
I only noticed this with wireguard so I will send the changes
If we execute `wg --version` we get a diffrent version string that does
not match with the version string in the openwrt makefile.
Current version string:
`wireguard-tools vreboot-13159-gac5caa2718
-https://git.zx2c4.com/wireguard-tools/`
Corrected versions string:
`wireguard-tools v1.0.20200319
Hauke Mehrtens writes:
> I also get this problem with mainline kernel.
>
> See here for some more details:
> https://bugs.openwrt.org/index.php?do=details&task_id=2928
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506
Hello,
I wondered what the current state of this is? Reading that GCC bug
The DIR-860L B1 has an MT7603 radio but was missing the corresponding
kmod-mt7603 module in DEVICE_PACKAGES.
Add this so it gets included by default, even when the kmod gets set to [m].
Signed-off-by: Stijn Segers
---
target/linux/ramips/image/mt7621.mk | 2 +-
1 file changed, 1 insertion(+), 1
Hey,
>
> root@localhost:~# mmcli -b 2
>
> General| dbus path:
> /org/freedesktop/ModemManager1/Bearer/2
> | type: default
>
> Status | connected: yes
>
> On 12 May 2020, at 06:54, Rafał Miłecki wrote:
>
> On 2020-05-12 01:45, Daniel Golle wrote:
>> Program received signal SIGSEGV, Segmentation fault.
>> main_autofs (argv=, argc=)
>>at fstools-2020-05-06-eec16e2f/block.c:1193
>> 1193:if (!m->autofs && (mp = find_mount_point(pr->dev))) {
22 matches
Mail list logo
