dolphs

  • Content Count

    262
  • Joined

  • Last visited

Everything posted by dolphs

  1. Hmmm why moving to 11 already, better wait till bullseye hit the streets imho... Perhaps you ae better off with backports? I do similar for unbound ( wireguard-tools )? eg: Last, but not least, dont know if you have emmc installed but you might test bullseye from sdcard? Compiling with EXPERT=yes, eg for rockpi-4a ( my scenario ):
  2. looks like this helped in the end: " rockpi-4a:~:# vnstat -i wg0 --update "
  3. Just flashed rockpi-4a current buster image and it looks like I hit " Error: Unable to read database "/var/lib/vnstat/wg0": No such file or directory Merge "eth0+wg0" failed. ", which can be shown here Also have been checking vnstat to merge wg0 but did not succeed, perhaps one can give me a hand please? TiA! These are the adapters present:
  4. bumped my OpiOnePlus H6 boards to kernel 5.12 and surprise surprise , BBR is working as it should again ... I really wonder what was causing this as in kernel 5.10 and 11 I had to use westwood ( with cake )... net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr shows 250Mbit ( meanwhile line upgraded which is max upload speed ) root@vpn01:~# iperf3 -4 -c 192.168.10.2 -t 300 -b0 -P1 Connecting to host 192.168.10.2, port 5201 [ 5] local 192.168.20.2 port 47462 connected to 192.168.10.2 port 5201 [ ID] Interval Transfer Bitrate Re
  5. 5.11 to be buried, is EOL ( already ). imho the non LTS kernels could be buried once mainline kernel hits .1 release. Thus eg. when 5.13.1 will be released bump edge kernel asap so 5.12 can be buried ( and forgotten ) ( needless to say , but "currents" should stay on LTS )
  6. Hello to you all, Haven't read 2825 yet, will do after this but did a quick checkout and built both for H6 (opioneplus) and H616( zero2 ), : git pull sed -i 's/orange-pi-5.11/orange-pi-5.12/g' config/sources/families/include/sunxi64_common.inc ./compile.sh EXPERT=yes EXTRAWIFI=no USEALLCORES=yes compilation.log shows --- grep error output/debug/*.log output/debug/compilation.log:drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c:152:27: error: redefinition of ‘sun50i_h616_r_ccu_clks’ output/debug/compilation.log:drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c:178:9:
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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?!
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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 )
  19. 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]
  20. 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 ....
  21. looks like 5.9 images are being published as recommended, therefore suppose fix/workaround is in place ? That would be very nice!
  22. Ordered 1Gb version incl housing just now , let's hope at least WIP status will appear next few months for this one.
  23. Looks like updating " /etc/default/keyboard " would be sufficient then to roll things back : " sed -i 's/us,ro/us/g' /etc/default/keyboard ". I'd propose to have this manually controlled ( thru personal settings in armbian-config ) and leave "us" default. cat /etc/default/locale # looks fine default # File generated by update-locale LC_MESSAGES=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LANG=en_US.UTF-8