Looks like the new dnsmasq 2.83 (and the patched 2.80 in 19.07) cause massive
log spam, in style of:
Fri Jan 22 06:30:09 2021 daemon.err dnsmasq[14996]: failed to send packet:
Network unreachable
Fri Jan 22 06:30:14 2021 daemon.err dnsmasq[14996]: failed to send packet:
Network unreachable
Hi!
On Fri, Jan 22, 2021 at 11:28 AM DENG Qingfang wrote:
>
> Hi,
>
> On Thu, Jan 21, 2021 at 5:37 PM David Bauer wrote:
> >
> > Is this dependent on board design? The need for the old hack should be
> > fixed by
> > this upstream commit [0]. Given that commit adds SNOR_F_4B_OPCODES for the
>
Hi,
On Thu, Jan 21, 2021 at 5:37 PM David Bauer wrote:
>
> Is this dependent on board design? The need for the old hack should be fixed
> by
> this upstream commit [0]. Given that commit adds SNOR_F_4B_OPCODES for the
> mx25l25635f, it should in turn disable the hack enabled by
>
On Thu Jan 21, 2021 at 9:42 AM HST, Adrian Schmutzler wrote:
> On a platform with many very different devices, like found on ath79,
> the generic profiles seem like remnants of the past that do not
> have a real use anymore.
>
> Remove them to have one thing less to maintain.
>
> Signed-off-by:
Hi, Adrian
El jue, 21 ene 2021 a las 23:13, Adrian Schmutzler
() escribió:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Daniel González Cabanelas
> > Sent: Donnerstag, 21. Januar 2021 22:06
> > To:
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel González Cabanelas
> Sent: Donnerstag, 21. Januar 2021 22:06
> To: openwrt-devel@lists.openwrt.org
> Cc: yn...@true.cz; nolt...@gmail.com
> Subject: [PATCH 18.06 1/2]
The GPIO hog feature is broken for bcm63xx in the 18.06 release. As a
result of this, the whole GPIO infrastructure will fail, causing a non
working LEDs problem and empty GPIOs when a hog is requested at boot time.
[0.537448] requesting hog GPIO usb-hub-reset-gpio (chip bcm63xx-gpio.0,
Backport 5af04f0d94a229 commit:
Add missing pin controls for the Observa VH4032N router.
This fixes the wifi radio and ethernet LAN LEDs.
Problem reported at forum post:
https://forum.openwrt.org/t/openwrt-wifi-issue-in-observa-vh4032n
Signed-off-by: Daniel González Cabanelas
---
Dear Author,
You are invited to participate in these 2 Important (online) conferences
without fees
in the Proceedings and in some of their Journals:
17th International Conference on Environment, Geology and MaterialsMarathon
Beach,
On a platform with many very different devices, like found on ath79,
the generic profiles seem like remnants of the past that do not
have a real use anymore.
Remove them to have one thing less to maintain.
Signed-off-by: Adrian Schmutzler
---
This might also apply to other similar targets like
Update the ca-certificates and ca-bundle package from version 20200601 to
version 2021019.
This version uses Python 3 for the build, fixing a build issue on systems,
where `/usr/bin/python3` is a wrapper script [1].
Debian change-log entry [2]:
> [ Julien Cristau ]
> * New maintainer
Hi Rafał,
On 2021-01-21 16:57, zajec5 at gmail.com (Rafał Miłecki) wrote:> On
21.05.2017 22:22, Rafał Miłecki wrote:
On 14 March 2017 at 07:37, Rafał Miłecki wrote:
My current DTS file contains following entry:
bootargs = "console=ttyS0,115200"
and it works in a following way:
Press the [f]
Since generic images have been split to their own
Makefile boards are showing up twice in menuconfig
as $(eval $(call BuildImage)) was not dropped from
the new generic.mk.
Hence $(eval $(call BuildImage)) was being called
twice.
So, lets simply drop it from generic.mk.
Fixes: 378c7ff28210
From: Rafał Miłecki
Asus looks for an extra data at the end of BCM4908 image, right before
the BCM4908 tail. It needs to be properly filled to make Asus accept
firmware image.
This tool constructs such a tail, writes it and updates CRC32 in BCM4908
tail accordingly.
Signed-off-by: Rafał
Hi,
On 1/21/21 5:21 AM, DENG Qingfang wrote:
> The kernel bump to 5.4 removed the mx25l25635f hack, and the upstream
> property "broken-flash-reset" should be used instead.
Is this dependent on board design? The need for the old hack should be fixed by
this upstream commit [0]. Given that commit
On 21.05.2017 22:22, Rafał Miłecki wrote:
On 14 March 2017 at 07:37, Rafał Miłecki wrote:
My current DTS file contains following entry:
bootargs = "console=ttyS0,115200"
and it works in a following way:
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4]
16 matches
Mail list logo