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" xrx200-
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" \
+
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)
-
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
openwrt-18.06,
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.
Signe
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 link:d
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
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 por
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 D
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 TL-MR6400
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:
ð0 {
status = "okay";
phy-mode = "mii";
phy-handle = <&swphy0>;
mtd-mac-address = <&uboot 0x1fc
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 develo
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 ---
>But I don't have ath79 version of
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
>
> H
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 initi
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
--
Run-tested
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 correctl
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: Dienstag
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 +++
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
"
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 --
target/linux/ath79/d
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
---
target/linux/ramips/dts/mt7620a_aigale_ai-br10
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 -
target/linux/ramips/d
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 the
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 th
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:
ð0 {
status = "okay";
phy-handle = <&swphy0>;
mtd-mac-addres
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&task_id=2480
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
> > "gener
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] [PATCH]
30 matches
Mail list logo
