Re: RC3 seems okay on Archer A6 v3 (US)

2021-06-19 Thread Nathan Lutchansky

On Fri, 18 Jun 2021, Nathan Lutchansky wrote:

2.4Ghz and 5Ghz radios work more or less okay.  The only issues I've 
encountered are reminiscent of my experience with the EAP235-Wall (lack of 
DFS; timeouts after repeated configuration changes, particularly when 
unsupported frequencies are selected) so I'm pretty sure they're mt76 issues 
rather than anything specific to this board.  Once a supported configuration 
is up and running, it's been solid.


After a little more testing I suspect I'm running into FS#3873.  I can 
work around it by setting up the desired /etc/config/wireless, then 
shutting down and doing a cold power cycle.  (Rebooting is not 
sufficient.)  Once it comes up, it's stable, as long as I don't touch the 
5Ghz configuration again.


I'll do more testing early next week with both the Archer A6 v3 and the 
EAP235-Wall to see if I can add more useful information to the issue 
tracker.  -Nathan


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 1/3] base-files: failsafe: Fix IP configuration

2021-06-19 Thread Hauke Mehrtens
Adapt the preinit_config_board() to the board.json network changes. It
now looks for the device and the ports variables to configure the LAN
network.

This works with swconfig configurations.

Fixes: FS#3866
Fixes: d42640e389a8 ("base-files: use "ports" array in board.json network for 
bridges")
Signed-off-by: Hauke Mehrtens 
---
 .../files/lib/preinit/10_indicate_preinit  | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit 
b/package/base-files/files/lib/preinit/10_indicate_preinit
index 3c5992979016..ae9fcfecc89e 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -72,28 +72,34 @@ preinit_config_board() {
 
json_select network
json_select "lan"
-   json_get_vars ifname
+   json_get_vars device
+   json_get_values ports ports
json_select ..
json_select ..
 
-   [ -n "$ifname" ] || return
+   [ -n "$device" -o -n "$ports" ] || return
+
+   # swconfig uses $device and DSA uses ports
+   [ -z "$ports" ] && {
+   ports="$device"
+   }
 
# only use the first one
-   ifname=${ifname%% *}
+   ports=${ports%% *}
 
if [ -x /sbin/swconfig ]; then
# configure the switch, if present
 
json_get_keys keys switch
for key in $keys; do
-   preinit_config_switch $key $ifname
+   preinit_config_switch $key $ports
done
else
# trim any vlan ids
-   ifname=${ifname%\.*}
+   ports=${ports%\.*}
fi
 
-   pi_ifname=$ifname
+   pi_ifname=$ports
 
preinit_ip_config $pi_ifname
 }
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA

2021-06-19 Thread Hauke Mehrtens
On a DSA switch the ports have an upper device, the CPU device, e.g.
eth0. This device has to be in up state to bring up the lower devices
like lan1.

Parse the link device from "ip link show" and bring it into up stated
before bringing up the actual interface.

This is needed to make network in failsafe on systems with DSA work.

Signed-off-by: Hauke Mehrtens 
---
 package/base-files/files/lib/preinit/10_indicate_preinit | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit 
b/package/base-files/files/lib/preinit/10_indicate_preinit
index ae9fcfecc89e..a3bc289dd663 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -12,6 +12,12 @@ preinit_ip_config() {
fi
 
grep -q "$netdev" /proc/net/dev || return
+   
+   # Get the link interface e.g. eth0 in lan1@eth0
+   iflink=$(ip link show dev ${netdev} |sed -nr 's/.*@([a-zA-Z0-9]*): 
.*/\1/p')
+   if [ -n "$iflink" ]; then
+   ip link set dev $iflink up
+   fi
 
if [ -n "$vid" ]; then
ip link add link $netdev name $1 type vlan id $vid
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 3/3] base-files: failsafe: Remove the VLAN modifier from interface name

2021-06-19 Thread Hauke Mehrtens
Some interfaces have a VLAN modifier like :t in lan1:t, this modifier
should be removed from the interface before calling preinit_ip_config().

Signed-off-by: Hauke Mehrtens 
---
 package/base-files/files/lib/preinit/10_indicate_preinit | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit 
b/package/base-files/files/lib/preinit/10_indicate_preinit
index a3bc289dd663..2fa812e91f73 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -103,6 +103,8 @@ preinit_config_board() {
else
# trim any vlan ids
ports=${ports%\.*}
+   # trim any vlan modifiers like :t
+   ports=${ports%\:*}
fi
 
pi_ifname=$ports
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


realtek: Traffic directly on lanX not working

2021-06-19 Thread Hauke Mehrtens

Hi,

I am unable to send and receive packets directly on the lan1 interface 
when it is not part of a bridge.


I have seen this on today's OpenWrt master.

I changed the OpenWrt network configuration like this:
--
root@OpenWrt:/# cat /etc/config/network

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd39:7fe0:0309::/48'

config device
option name 'lan1'
option macaddr '9a:0d:67:06:9a:40'

config interface 'lan'
option device 'lan1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

root@OpenWrt:/#
--

The interface is configured and brought up correctly:
--
root@OpenWrt:/# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1504 qdisc mq state UP 
group default qlen 1000

link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff
inet6 fe80::9a0d:67ff:fe06:9a40/64 scope link
   valid_lft forever preferred_lft forever
3: lan1@eth0:  mtu 1500 qdisc noqueue 
state UP group default qlen 1000

link/ether 9a:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global lan1
   valid_lft forever preferred_lft forever
inet6 fd39:7fe0:309::1/60 scope global noprefixroute
   valid_lft forever preferred_lft forever
inet6 fe80::980d:67ff:fe06:9a40/64 scope link
   valid_lft forever preferred_lft forever
4: lan2@eth0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000

link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff
.
--

I see that some packets are received, but the RX counter do not increase 
anymore:

--
root@OpenWrt:/# ip -s link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes  packets  errors  dropped missed  mcast
117616 1497 0   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
117616 1497 0   0   0   0
2: eth0:  mtu 1504 qdisc mq state UP 
mode DEFAULT group default qlen 1000

link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff
RX: bytes  packets  errors  dropped missed  mcast
81280   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
7310   62   0   0   0   0
3: lan1@eth0:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000

link/ether 9a:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff
RX: bytes  packets  errors  dropped missed  mcast
66880   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
4972   46   0   0   0   0
4: lan2@eth0:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000

link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff
RX: bytes  packets  errors  dropped missed  mcast
0  00   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
0  00   0   0   0
.
--

In wireshark on a connected host I do not see any packets from this 
device, but the link is up.


When I use OpenWrt's default network configuration using a bridge, 
network works like expected.
I took care of the VLAN 100 which is used by default, but this setup 
does not use any VLAN.


I would like to use a very similar configuration for the failsafe mode 
which is also not working correctly.


Hauke


OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH uclient] uclient-fetch: allow to overwrite Content-Type header for POST

2021-06-19 Thread Baptiste Jonglez
Hi,

On 03-06-21, Andre Heider wrote:
> This is required by some APIs, e.g. matrix's media upload [0].
> 
> [0] 
> https://matrix.org/docs/spec/client_server/latest#post-matrix-media-r0-upload


> @@ -484,6 +485,7 @@ static int usage(const char *progname)
>   "   --user-agent | -U  Set HTTP user agent\n"
>   "   --post-data=STRING  use the POST method; 
> send STRING as the data\n"
>   "   --post-file=FILEuse the POST method; 
> send FILE as the data\n"
> + "   --content-type=STRING   use STRING as 
> Content-Type for the POST method\n"
>   "   --spider | -s   Spider mode - only 
> check file existence\n"
>   "   --timeout=N | -T N  Set connect/request 
> timeout to N seconds\n"
>   "   --proxy=on | -Y on  Enable interpretation 
> of proxy env vars (default)\n"

As far as I can tell, GNU wget does not have such an option.  We try to
stay compatible whenever possible, so adding a new custom option is not
a good idea.

How would you solve this problem with GNU wget?  Reading the man,
--post-data and --post-file are really meant to transmit data in
"application/x-www-form-urlencoded" format, not as arbitrary data.  But if
it is still possible with a custom --header for instance, we should be
able to do the same in uclient-fetch.

Otherwise, maybe curl will do a better job at this.

Regards,
Baptiste


signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 5/5] tegra: make target source-only

2021-06-19 Thread Raylynn Knight via 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 Jun 17, 2021, at 10:26 AM, Koen Vandeputte  
> wrote:
> 
> 
> On 16.06.21 15:43, Tomasz Maciej Nowak wrote:
>> W dniu 15.06.2021 o 16:05, Koen Vandeputte pisze:
>>> On 13.06.21 18:28, Tomasz Maciej Nowak wrote:
 Looking at OpenWrt downloading statistics this target has non-existent
 userbase apart from me. Mark it as source-only to skip the build by
 buildbots and not waste further the resources.
 
 Signed-off-by: Tomasz Maciej Nowak 
 ---
 
 I'll keep this target in good condition in forseable future. If anyone
 would suggest to drop the target, I'm not opposed.
>>> I've been thinking for some time to try to support nvidia Jetson (and some 
>>> carrier boards)
>> Great, finally someone interested in this niche target.
> 
I would be interested in helping with this effort.   I can provide testing with 
the following Tegra Devices:

Compulab Trimslice
TK1
TX1
TX2
Nano
Nano 2GB

Ray







signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel