On 2019-09-16 22:43, Hauke Mehrtens wrote:
On 9/16/19 7:09 PM, Martin Blumenstingl wrote:
Hi Martin,
On Mon, Sep 16, 2019 at 12:54 PM Martin Schiller
wrote:
Hi!
I am searching for a possibility to disable Auto Negotiation of an
PEF7072 which is attached to MAC1 of the Lantiq xrx200
On Sun, 15 Sep 2019 at 12:49, Paul Spooren wrote:
> > What you suggest is about what we have right now. This kind of creates a
> > misleading situation where for some targets subtargets are present, while
> > for others paths and image names are "fixed" in several places to include a
> >
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Enrico Mioso
> Sent: Dienstag, 17. September 2019 02:21
> To: openwrt-devel@lists.openwrt.org
> Cc: Filip Moc ; Piotr Dymacz ; Enrico Mioso
>
> Subject: [OpenWrt-Devel]
On Sun, 8 Sep 2019 at 21:19, Tom Psyborg wrote:
> there seem to exist at least a dozen of critical bugs that one would
> not like to have as a part of final release, to name a few:
>
> Mainline ath10k causes crahes in ipq806x / R7800 ->
> https://bugs.openwrt.org/index.php?do=details_id=2480
We
thank you very very much Adrian!! I'll address all of the comments hopefully,
and send a new version. In the meantime I am trying to configure the switch
correctly, which is not the case.
My current snippet is:
{
status = "okay";
phy-handle = <>;
mtd-mac-address = <
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,
> Here, you assign eth1 to
This is the result of grepping/searching for several common
whitespace issues like double empty lines, leading spaces, etc.
This patch fixes them for the ath79 target.
Signed-off-by: Adrian Schmutzler
---
target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts| 2 --
Hi David,
since C59v2 had to be added anyway, I've sent a v2 patchset with a different
approach.
Just wanted to notify you also in this thread, as you have marked this as Under
Review.
Best
Adrian
> -Original Message-
> From: David Bauer [mailto:m...@david-bauer.net]
> Sent:
This converts all remaining devices to use interrupt-driven
gpio-keys compatible instead of gpio-keys-polled.
The poll-interval is removed.
While at it, add/remove newlines in keys and leds node where
necessary.
Signed-off-by: Adrian Schmutzler
---
This is the result of grepping/searching for several common
whitespace issues like double empty lines, leading spaces, etc.
This patch fixes them for the ramips target.
Signed-off-by: Adrian Schmutzler
---
target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts | 1 -
So far, for the ZBT-WE826-E the leds pulled from the DTSI are
deleted and then redefined. The config in the DTSI is then used
in two other DTSes for the ZBT-WE826 flash variants.
Since the block is effectively only used for two devices, this
moves led definitions to the device DTSes to prevent
Several devices added to LED migration script will just have their
(old) board name converted to tp-link.
By using a variable for this, the amount of code in the migration
script can be reduced and the chance for typos is reduced.
This patch also introduces the marker for beginning of a pattern
Several Archer Cxx devices were using board-specific LED names in
ar71xx, which were changed to "tp-link:*" in ath79.
This patch adds migration for them.
Signed-off-by: Adrian Schmutzler
---
v2: Added C59v2, use new concept
---
.../base-files/etc/uci-defaults/04_led_migration | 12
Hi,
> I am investigating it.
> Still, something is wrong if I don't see interface events when unplugging the
> cable, right?
For that topic, maybe have a look at:
https://github.com/openwrt/openwrt/pull/1942#issuecomment-529078064
This might not apply 1:1 for your device, but essentially the
Thanks! I'll take a look now.
Still, something should be interestingly wrong here:
root@OpenWrt:/# swconfig dev switch0 show|grep -i link
link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
link: port:1 link:up speed:100baseT full-duplex auto
link: port:2
Hi,
> Issues:
> switch configuration currently broken (port 2 on device is seen as port 3,
> port
> 3 as port 2).
If it's only that, just do:
+ tplink,tl-mr6400-v1)
+ ucidef_set_interfaces_lan_wan "eth0.1 eth1" "usb0"
+ ucidef_add_switch "switch0" \
+
Hi,
> -Original Message-
> From: Enrico Mioso [mailto:mrkiko...@gmail.com]
> Sent: Dienstag, 17. September 2019 18:57
> To: Filip Moc
> Cc: Adrian Schmutzler ;
> openwrt-devel@lists.openwrt.org; Piotr Dymacz
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link
Hello all,
thand thank you very very much for your kind help, and patience.
Adrian, you're a tireless reviewer, and to you my gratitude.
To you filip as well - very much thank you for your insight, I'll do the
testing of the different ports ASAP!! :)
Dear Piotr,
I added you in CC since you
BTW I can see the code for setting up network interfaces in mach-tl-mr6400.c is
identical to the one in mach-fritz4020.c for which we have ath79 support.
Hence, I copied the setup from there:
{
status = "okay";
phy-mode = "mii";
phy-handle = <>;
mtd-mac-address = < 0x1fc00>;
This version fixes 3 low-severity vulnerabilities:
- CVE-2019-1547: ECDSA remote timing attack
- CVE-2019-1549: Fork Protection
- CVE-2019-1563: Padding Oracle in PKCS7_dataDecode and
CMS_decrypt_set1_pkey
Patches were refreshed, PKG_SOURCE_URL was updated to match
This version fixes 3 low-severity vulnerabilities:
- CVE-2019-1547: ECDSA remote timing attack
- CVE-2019-1549: Fork Protection
- CVE-2019-1563: Padding Oracle in PKCS7_dataDecode and
CMS_decrypt_set1_pkey
Patches were refreshed, and Eneas U de Queiroz added as maintainer.
This device is an LTE router supported in ar71xx.
As per original commit, hardware specifications (v1.0 EU):
- SoC: QCA9531
- Flash: Winbond W25Q64FV (8MiB)
- RAM: EtronTech EM6AB160TSE-5G (64MiB)
- Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
- Ethernet: 2NIC (3x100M + 1x100M)
I am investigating it.
Still, something is wrong if I don't see interface events when unplugging the
cable, right?
On Tue, 17 Sep 2019, Adrian Schmutzler wrote:
Date: Tue, 17 Sep 2019 19:02:12
From: Adrian Schmutzler
To: Enrico Mioso , Filip Moc
Cc: openwrt-devel@lists.openwrt.org, Piotr
Hi,
> > As stated above, this will make eth1 part of "lan" ...
> I don't think you can have two interfaces in one network unless you use
> bridge which you definitely don't want to use in this case.
Well, I would have expected that this adds eth0.1 and eth1 to br-lan, which is
a bridge.
Haven't
On 2019-09-17 08:51, Martin Schiller wrote:
Meanwhile I found out that there is a mechanism with swconfig to
configure
the link attributes:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6219b3deae1c8dfbf405f5a701d3f3b00ebacce1
I will try to integrate this into the "old"
This version fixes 3 low-severity vulnerabilities:
- CVE-2019-1547: ECDSA remote timing attack
- CVE-2019-1549: Fork Protection
- CVE-2019-1563: Padding Oracle in PKCS7_dataDecode and
CMS_decrypt_set1_pkey
Patches were refreshed.
Signed-off-by: Eneas U de Queiroz
--
To anyone with DTS and qcom MDIO/ESS knowledge,
please help, you are my only hope.
Using an QCOM ap.dk04.1-c1 / ipq4019 device,
I ran into an initialization problem for MDIO driver.
The problem only appeared when I started booting from the device,
because executing 'dhcp' in uboot , do some
It has been reported that using the sysupgrade-tar image will trigger
"lzma_decode failed error". The RedBoot bootloader always loads data
from flash till block size boundary, so if there's no padding it'll also
load the beginning of rootfs, and it seems that lzma_decoder can't handle
that garbage
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,
> Where - eth1 works
Hi,
> -Original Message-
> From: Filip Moc [mailto:l...@moc6.cz]
> Sent: Dienstag, 17. September 2019 15:52
> To: Enrico Mioso
> Cc: Adrian Schmutzler ;
> openwrt-devel@lists.openwrt.org; Piotr Dymacz
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-MR6400
>
>
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 ---
>But I don't have ath79 version
31 matches
Mail list logo
