dolphs

cheers for your response. eth0, eth1 solved by " extraargs=net.ifnames=0 " as @Igor pointed out in this topic I cut down iptables script to the basics as shown below , allowing SSH on eth1 only and outbound traffic goes over eth0. #!/bin/sh # Delete all existing iptables rules iptables -F # Set default chain policies to DROP all iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP # Allow SSH on eth1 iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp --sport 22 -m state

Hi, Idea is to run a wireguard server having two ethernet devices, therefore added an USB3 adapter "ASIX AX88179" to my rockpi4a. I like to allow incoming traffic, incl SSH, on "eth1". Instead, outgoing, on eth0 ( RTL8211E ) I wrote following ( preps, nmcli, iptables ) up - but perhaps there is an easier approach and I am sure I am missing other (routing) stuff, for sure the forwarding part. Anyway perhaps there is one to guide me a bit, TiA! 1/ preparations apt update && apt -y upgrade && apt -y

fantastic, thanks for your answer Igor I was already about to mess with " 73-usb-net-by-mac.rules ", but this flag works so much better! Out of the box, flashing image it shows: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 86:67:c3:ba:43:ca brd ff:ff:ff:ff:ff:ff inet 192.168.10.188/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0 valid_lft 14213sec preferred_lft 14213sec inet6 fe80::f791:3c34:96fb:aec3/64 scope link noprefixroute valid_lft forever preferred_lft forever

Hi, I added an USB3.0 adapter to my rockpi4a , which results in: " enx000ec667f0a2 " ( eth1 ) Since NetworkManager is being used I tried to update this name using : " nmcli c modify armbian connection.interface-name "eth1" " But alas that does not seem to be picked up while nmconnection config file has been updated: cat /etc/NetworkManager/system-connections/armbian.nmconnection [connection] id=armbian uuid=8f61a97c-d0f1-4cb2-be4a-3fe2b4c08e7c type=ethernet interface-name=eth1 <snip snip> Ideally this could be changed

no url to paste to, but 5.9.14 shows: root@rockpi-4a:~# cpufreq-info | grep 2.02 hardware limits: 408 MHz - 2.02 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz current policy: frequency should be within 408 MHz and 2.02 GHz. cpufreq stats: 408 MHz:77.49%, 600 MHz:2.96%, 816 MHz:0.26%, 1.01 GHz:0.17%, 1.20 GHz:0.13%, 1.42 GHz:0.12%, 1.61 GHz:0.04%, 1.80 GHz:0.07%, 2.02 GHz:18.76% (288) hardware limits: 408 MHz - 2.02 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz

Hi, Just noticed image " Linux rockpi-4a 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 GNU/Linux " my rockpi4a runs at 2Ghz. To radxa overclocking is possible so that 2GHz is not a real surprise ... Though checked " armbianEnv.txt " but did not find any "overlays" option present overlocking this board, neither any other files in /boot ( or /boot/dtb/rockchip/overlay ). However building a custom image ( kernel 5.10 ) it is running at 1,8GHz again, how can I set this to 2GHz ? ( as a side note - tehre is no need to enable panf

tried my rockpi4a , similar results ( bad ) as H5 and H6. Once switched to legacy 4.4 kernel, things rock and faster results again. really wonder what is causing this: patch, kernel realtek driver, both / something else : lost?!

well I decided to bring in the r4s and flashed latest dev image ( 5.10.9-rockchip64 ). Long story short .. using westwood both ways seem to be meeting my needs, using bbr to site is also fine - but from site to home bbr is rubbish below results: - fresh dev image built r4s , connected to " enp1s0 " and results below - without changing anything: iperf3 -4 -c somewhere.dynu.net -t 300 -b 0 -P 1 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 5.10 MBytes 42.8 Mbits/sec 501 391 KBytes [ 5] 1.00-2.00 sec 3.7

at this stage I have continuous 40Mbit upload ( RPi4 ) and other way round ( H6 or H5 board ) : site to my Rpi4 disappointing speed using only these "tweaks" net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr [ 5] 0.00-1.00 sec 1.76 MBytes 14.8 Mbits/sec 0 110 KBytes [ 5] 1.00-2.00 sec 440 KBytes 3.60 Mbits/sec 0 102 KBytes [ 5] 2.00-3.00 sec 440 KBytes 3.60 Mbits/sec 0 93.5 KBytes [ 5] 3.00-4.00 sec 440 KBytes 3.60 Mbits/sec 0 96.2 KBytes [ 5] 4.00-5.00 sec 879 KBytes 7.20 Mbits/sec

hmm, this needs further analysis. It appears if I upload from my side ( where I currently reside ) to my remote site I get awful upload speeds on the H6 ( and H5 ) : ( no congestion even set ) and no VPN even : [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.57 MBytes 13.2 Mbits/sec 2 20.5 KBytes [ 5] 1.00-2.00 sec 440 KBytes 3.61 Mbits/sec 0 45.1 KBytes [ 5] 2.00-3.00 sec 880 KBytes 7.21 Mbits/sec 0 62.9 KBytes [ 5] 3.00-4.00 sec 880 KBytes 7.21 Mbits/sec 3 47.9 KBytes [ 5] 4.00-5.00

hmm , recently it came to my attention bbr between both wireguard servers is doing a very bad job: :/etc/sysctl.d# iperf3 -4 -c 192.168.10.2 -t 300 -b 0 -P 1 Connecting to host 192.168.10.2, port 5201 [ 5] local 192.168.20.2 port 41804 connected to 192.168.10.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.29 MBytes 10.8 Mbits/sec 0 112 KBytes [ 5] 1.00-2.00 sec 502 KBytes 4.11 Mbits/sec 0 104 KBytes [ 5] 2.00-3.00 sec 753 KBytes 6.17 Mbits/sec 0 98.9 KBytes [ 5] 3.00-4.00 sec 753 KByte

Device with housing arrived today, cannot wait to deploy armbian on it :-), but will need to have some more patience Once image is ready ( to be build ) and entered matured state will swap it with my OpiOnePlus as I'll solely use it for wireguard ( and ddclient / chrony )

done a few more ( approx 6 ) till now and all looking good, will start with cold boot early morning to see how things go and give a few more reboots after that. but seems to be fine on this H6 board, over to topic : OrangePi3 [EDIT] Meanswhile executed reboots and cold starts, OPiOnePlus came back OK all the time ( kernel 5.9.16 ) [/EDIT]

my spare OpiOnePlus has been upgraded , dont have Opi3 either. Anyway to see if the OPiOnePlus is unaffected will reboot few times today and see if it comes back online normally ....

looks like 5.9 images are being published as recommended, therefore suppose fix/workaround is in place ? That would be very nice!