26 Odpowiedź przez marcinkk

(11 odpowiedzi, napisanych Oprogramowanie / Software)

Po wielu próbach zaczęło działać. Co dokładnie dzieje się podczas "handszejku" nie wiem, ale urządzenie nie potrafią się dogadać. Odpaliłem na OpenWrt 19.07-SNAPSHOT r11328. Działa zarówno z wpad-mesh-wolfssl jak i wpad-mesh-openssl, działa też jeżeli na jednym z węzłów jest WolfSSL a na innym OpenSSL. A żeby zaskoczyło to przełączyłem tryb pracy z AC na N (mnóstwo klikania w LuCI, żeby zmienić z VHT40 na HT40 wink). Nie łapie od razu, ale działa:

Tue Jun  8 09:50:13 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-GROUP-STARTED ssid="mesh_5G" id=0
Tue Jun  8 09:50:13 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for d4:6e:0e:c6:0e:e6
Tue Jun  8 09:50:14 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:14 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:14 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:24 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=d4:6e:0e:c6:0e:e6
Tue Jun  8 09:50:26 2021 daemon.notice wpa_supplicant[1640]: wlan0: mesh plink with c4:6e:1f:40:9e:bc established
Tue Jun  8 09:50:26 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-PEER-CONNECTED c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:30 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=30:b5:c2:96:1b:9b
Tue Jun  8 09:50:31 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:31 2021 daemon.notice wpa_supplicant[1640]: wlan0: mesh plink with 30:b5:c2:96:1b:9b established
Tue Jun  8 09:50:31 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-PEER-CONNECTED 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:39 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=d4:6e:0e:c6:0e:e6
Tue Jun  8 09:50:50 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=d4:6e:0e:c6:0e:e6
Tue Jun  8 09:51:01 2021 daemon.notice wpa_supplicant[1640]: wlan0: mesh plink with d4:6e:0e:c6:0e:e6 established
Tue Jun  8 09:51:01 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-PEER-CONNECTED d4:6e:0e:c6:0e:e6

Idź do forum: Oprogramowanie / Software

27 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Teraz to próbujesz sobie wytłumaczyć pewne rzeczy. Zrób router normalnie podłączony do internetu, zrób na nim serwer openvpn, pojawią sie wykresy od openvpn. I tyle, bez tłumaczenia że ten ruch powinien czy nie być traktowany jako przez wan czy jako lokalny itd.

Z powodu wydajności to nie jest dla mnie opcja. Wolę stracić dane z wykresów.

A jak chodzi o brak tego ruchu na wykresach, to otworzyłem wątek na forum gargoyle-router.com i w teorii ten ruch powinien tam być, ale może go nie być z powodu włączonego "flow offloading".

BTW: Nie wiem czy dobrze szukam, ale jeżeli chciałbym spróbować coś zmodyfikować jak chodzi o te statystyki, to wszystko jest w /etc/init.d/bwmon_gargoyle? Nie ma żadnych plików konfiguracyjnych? Na tą chwilę mnie to przerasta sad

Idź do forum: Oprogramowanie / Software

28 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

jezy napisał/a:

2.  Ustawienia statycznych adresów IP z poziomu gui gagroyle powoduje odcięcie od Internetu. Wybierałem urządzenia z listy, przypisywałem im adresy ip po czym wszystkie urządzenia w sieci traciły dostęp do Internetu. Trzeba było wyrzucić z listy adresów statycznych wszytskie zapisane urządzenia i dostęp do Internetu powracał. Rozwiązaniem była konfiguracja adresów statycznych w pliku etc/config/dhcp. PS : korzystam z połączenia pppoe.

Co prawda u mnie jeszce jest pre9, ale u mnie działa - wszystkie przypisanie konfigurowałem przez GUI.

Może włączyłeś opcję "Enforce DHCP assignments" a komputery miały jeszcze adresy przydzielone wcześniej z puli?

Idź do forum: Oprogramowanie / Software

29 Temat przez marcinkk

(11 odpowiedzi, napisanych Oprogramowanie / Software)

Temat może trochę dziwny, ale w sumie wyjaśnia problem.

Skonfigurowałem na TP-Link Archer C2 v1 sieć mesh 802.11s z szyfrowaniem WPA3-SAE. Jestem pewny, że wszystko dobrze ustawiłem (przećwiczyłem temat na Archerach C7 v5) ale połączyć się nie chciało. Po kilku chwilach szukania ustaliłem, że to jest istotne:

Sat May 29 13:44:31 2021 daemon.notice wpa_supplicant[1901]: wlan0: new peer notification for e8:94:f6:d0:d1:be
Sat May 29 13:44:31 2021 daemon.notice wpa_supplicant[1901]: wlan0: new peer notification for e8:94:f6:d0:d1:be
Sat May 29 13:44:31 2021 daemon.notice wpa_supplicant[1901]: wlan0: new peer notification for e8:94:f6:d0:d1:be
Sat May 29 13:44:41 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:44:58 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:45:13 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:45:28 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:45:28 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-BLOCKED addr=e8:94:f6:d0:d1:be duration=300

Przestawiłem mesha na tryb bez szyfrowania i faktycznie łączy się bez problemu. Z szyfrowaniem jak wyżej.

Może nie będę wielu linków podrzucał, ale sytuację dość dobrze wyjaśnia ten post: https://github.com/libremesh/lime-packa … -842034728. Człowiek pisze tutaj zdaje się o tej łatce: https://git.openwrt.org/?p=openwrt/open … 636116a35a.

Nie wiem czy faktycznie to jest powodem, ale zrozumiałem, że początkowy handshake w WPA3-SAE trwa zbyt długo, strony uznają, że wiadomości nie dotarły na czas i kwitują to komunikatem: MESH-SAE-AUTH-FAILURE. Mówiąc krótko: za wolny procesor sad Z OpenSSL też mi nie działa sad

Człowiek, który opisał problem w tym poście na GitHubie ma OpenWrt 19.07.6 a tam libwolfssl24 - 4.6.0-stable-1 oraz wpad-mesh-wolfssl - 2019-08-08-ca8c2bd2-4. W repozytoriach nie ma już tej wersji biblioteki WolfSSL ani wpad-mesh-wolfssl, ma ktoś może taki zabytek, żebym mógł u siebie podmienić i przetestować? Ktoś bardziej biegły niż ja mógłby sprawdzić w źródłach, czy ta poprawka, do której link podałem jest ciągle aktywna?

Idź do forum: Oprogramowanie / Software

30 Odpowiedź przez marcinkk

(1 odpowiedzi, napisanych Oprogramowanie / Software)

Ja przeszedłem na 1.13 z powodu "flow offloading". Też używam OpenVPNa, żeby dostać się do zasobów LAN. 10Mbit/s wyciagnałem a to chyba jest limit procesora przy szyfrowaniu. Tak na szybko wyniki z iperf (przez OpenVPN na Archer C7 v4 z Gargoyle 1.13):

# iperf -s -p 6001
------------------------------------------------------------
Server listening on TCP port 6001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  1] local 192.168.32.2 port 6001 connected with 172.16.32.2 port 59414
[ ID] Interval       Transfer     Bandwidth
[  1] 0.00-10.15 sec  15.9 MBytes  13.1 Mbits/sec
[  2] local 192.168.32.2 port 6001 connected with 172.16.32.2 port 59419
[ ID] Interval       Transfer     Bandwidth
[  2] 0.00-10.21 sec  15.4 MBytes  12.6 Mbits/sec
[  3] local 192.168.32.2 port 6001 connected with 172.16.32.2 port 59427
[ ID] Interval       Transfer     Bandwidth
[  3] 0.00-10.17 sec  15.4 MBytes  12.7 Mbits/sec

Idź do forum: Oprogramowanie / Software

31 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Drugie: bo statytyki obejmuję ruch przez wan, tak jest gargoyle zbudowane.

W praktyce jest to ruch przez WAN. Bo to jest ruch pomiędzy "jakimś komputerem w Internecie" a "jakimś komputerem w sieci lokalnej". Nie do końca rozumiem jak działa przekierowanie portu, ale wnioskuję, że jeżeli postawiłem serwer OpenVPN w sieci lokalnej i zrobiłem przekierowanie na routerze, to taki ruch jest interpretowany jako "pomiędzy routerem a serwerem lokalnym"?

Idź do forum: Oprogramowanie / Software

32 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

A tak z innych spraw.

Zostało mi trochę miejsca na routerze, to pomyślałem, że może pełne SSH bym sobie zainstalował. Insrukcję znalazłem - https://oldwiki.archive.openwrt.org/inb … nsshserver - skomplikowana nie jest, ale pytanie jest następujące: Czy nie posypie mi się interfejs konfiguracyjny Gargoyle, kiedy zainstaluję OpenSSH zamiast dropbear? A może lepiej zainstalować SSH obok, tylko odpowiednio porty przydzielić, zablokować dropbear na świat a odblokować (z terminala) wyjście przez OpenSSH?

I druga sprawa: Jako, że wydajność OpenVPNa na C7 nie jest powalająca, to skonfigurowałem tunel z komputerem wewnątrz sieci. Ogólnie działa ... ale statystyki ruchu w Gargoyle traktują ten ruch jako lokalny i nie pokazują na wykresach. Mogę z tym coś zrobić?

Idź do forum: Oprogramowanie / Software

33 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Na tyle na ile ostatnio przetrenowałem WireGuarda, to w kliencie w Windows powinieneś mieć:

AllowedIPs = 10.64.0.1/24, 192.168.1.0/24

lub tak:

AllowedIPs = 10.64.0.0/24, 192.168.1.0/24

Idź do forum: Oprogramowanie / Software

34 Odpowiedź przez marcinkk

(47 odpowiedzi, napisanych Oprogramowanie / Software)

Może będzie mniej podejrzane, jak napiszę, że testowałem w trybie "ROUTING" a nie "NAT".

-----

Poprzednie wyniki, to rezultaty uzyskane na szybko przez podmianę na chwilę Drayteka Vigor 2960 (Draytek szwankował, stąd testy) na testowane urządzenia i wykonanie szybkiego sprawdzenia parametrów łącza na speedtest.net (i tak byli tacy co zauważyli brak internetu przez 2 minuty). Draytek daje radę 940/940.

-----

Ale jako, że temat mnie trochę męczył, to zrobiłem"pomiary" za pomocą iperf (wszystko w trybie routing, czyli po prostu dwukierunkowy forward z akceptowaniem wszystkiego):

  1. Xiaomi Router 4A Gigabit (czyli MT7621):

    • tylko software offloading

    • z włączonym wsparciem sprzętowym

  2. TP-Link Archer C7 v4:

    • bez offloading

    • tylko software offloading

    • z włączonym wsparciem sprzętowym (którego ten model nie ma)

4A, software ofloading, linux -> windows:

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.66 port 56189 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   958 MBytes   803 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.66 port 56207 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   897 MBytes   752 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.66 port 56241 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   899 MBytes   753 Mbits/sec

4A, software ofloading, windows -> linux:

# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37076 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   563 MBytes   472 Mbits/sec
# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37078 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   941 MBytes   789 Mbits/sec
# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37080 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   563 MBytes   472 Mbits/sec
# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37082 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   658 MBytes   552 Mbits/sec
# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37084 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   942 MBytes   790 Mbits/sec

4A, hardware ofloading, linux -> windows:

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.66 port 59506 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   929 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.66 port 59553 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   929 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.66 port 59698 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   936 Mbits/sec

4A, hardware ofloading, windows -> linux:

# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37086 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   929 Mbits/sec
# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37088 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   931 Mbits/sec
# iperf -c 192.168.1.66
------------------------------------------------------------
Client connecting to 192.168.1.66, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.14 port 37090 connected with 192.168.1.66 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec

C7, po 3 wyniki bez offloading, z software offloading, w włączoną opcją hardware:

# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 55475
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   324 MBytes   271 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 55622
[  4]  0.0-10.0 sec   329 MBytes   275 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 55766
[  4]  0.0-10.0 sec   329 MBytes   276 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 53877
[  4]  0.0-10.0 sec  1.04 GBytes   891 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 53921
[  4]  0.0-10.0 sec  1.04 GBytes   893 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 56092
[  4]  0.0-10.0 sec  1.02 GBytes   876 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 50715
[  4]  0.0-10.0 sec  1.01 GBytes   870 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 50732
[  4]  0.0-10.0 sec  1.03 GBytes   887 Mbits/sec
[  4] local 192.168.32.14 port 5001 connected with 192.168.1.66 port 50752
[  4]  0.0-10.0 sec  1.05 GBytes   897 Mbits/sec

Tak do kompletu - wyniki bez routera po drodze (jakieś switche były...):

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.21 port 54142 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   931 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.21 port 54200 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.21 port 54205 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.06 GBytes   912 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.21 port 54213 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   926 Mbits/sec

>iperf -c 192.168.32.14
------------------------------------------------------------
Client connecting to 192.168.32.14, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.32.21 port 54218 connected with 192.168.32.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   926 Mbits/sec

Na obydwu sprzętach miałem OpenWrt 21.02-SNAPSHOT (r16090-bbbc01ede5) z eko.one.pl. Testowane systemy: Windows 10 20H2 i Ubuntu Server 18.04.

W mojej domowej sieci, to co przeszło przez C7 w trybie "software offloading" jest dla mnie całkiem wystarczające.

Jak chodzi o sprzęt w pracy, to powiedziałbym, że MT7621 daje radę w trybie hardware (celowałbym w ER-X, a nie 4A użytkowo), ale komentarz @chemik89 dotyczący stabilności tego rozwiązania trochę mnie martwi sad

Idź do forum: Oprogramowanie / Software

35 Odpowiedź przez marcinkk

(47 odpowiedzi, napisanych Oprogramowanie / Software)

Robiłem testy na 21.02-SNAPSHOT (r16090-bbbc01ede5) od Cezarego (chyba na tej wersji, pobierałem 19.05.2021 ok. 20:00, to już chyba była - ewentualnie na poprzedniej wersji z eko.one.pl).

Na WR1043ND, tylko software flow offloading, uzyskałem ok. 600Mbps/600Mbps (tutaj 19.07-SNAPSHOT).

Na Xiaomi 4A Gigabit (czyli MT7621) z włączaną opcją wsparcia sprzętowego poszło ok. 750Mbps/920Mbps - czyli lepiej, ale jeszcze odrobinę do 940/940 brakuje.

Jeżeli chciałbym na OpenWrt uzyskać pełną prędkość łącza gigabitowego to potrzebuję pewnie mocniejszy router. WRT3200ACM lub WRT1900ACS dadzą radę? Co jeszcze mógłbym rozważać?

Idź do forum: Oprogramowanie / Software

36 Odpowiedź przez marcinkk

(47 odpowiedzi, napisanych Oprogramowanie / Software)

Czy gdzieś można znaleźć listę urządzeń wspierających "Hardware flow offloading"? Czy to tylko MT7621?

Idź do forum: Oprogramowanie / Software

37 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

- nie możesz odtwarzać backupu  z innych modeli. A w szczególności nie możesz przenosić plików network i wireless, system też może być inny, pewnie parę innych jeszcze by się zalazło. Inne pliki (jak firewall, qos) możesz przenieść

Bardzo się przydała ta uwaga, jaką dostałem miesiąc temu. Dziękuję serdecznie smile Pilnowałem, żeby nie nadpisać bezpośrednio plików network, wireless oraz system a pozostałe przenosiłem ręcznie bez problemów pomiędzy 1043ND v3 i v4 oraz C7 v2 i v4. Tacy leniwi jak ja mogą ręcznie te 3 pliki poprawić, ale mówiąc serio, to w przeciwieństwie do firewalla czy DHCP to ustawienia tam zawarte można później bardzo szybko wyklikać w przeglądarce wink

Mam jeszcze jedno pytanie związane z zachowywaniem konfiguracji. Pytanie jest w sumie krótkie: Czy w przypadkach opisanych poniżej mogę robić sysupgrade z zachowaniem konfiguracji?

1) Mam OpenWrt 19.07 z openwrt.org i doinstalowałem wpad-openssl i FreeRADIUS skonfigurowałem sieć z RADIUSem i teraz chciałbym przejść na wersję z eko.one.pl?

2) Rezygnuję z Gargoyle 1.13 i przechodzę na czyste OpenWrt 19.07 z LuCi.

Ad. 1) Może nie do końca dobrze trafiłem z przykładem, ale chodzi mi o to, że doinstalowałem kilka rzeczy do systemu, których nie ma w czystym obrazie i czy taka nadmiarowa konfiguracja nie będzie sprawiała problemów?

Idź do forum: Oprogramowanie / Software

38 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Tamto zgłosiłem.

Tak mnie naszło: https://openwrt.org/docs/guide-user/net … unnel-luci
Skorzystałem z tego: https://github.com/richb-hanover/OpenWr … lbroker.sh
I zrobiłem sobie tunel 6in4.

Ogólnie działa. A czy to dobry pomysł, to jeszcze nie ustaliłem.

Mała propozycja korekty do /sbin/sysinfo.sh, zamiast:

IP=$(ubus call network.interface status '{"interface":"'$S'"}' 2>/dev/null | jsonfilter -q -e "@['ipv4-address'][0].address")
[ -z "$IP" ] && IP=$(uci -q -P /var/state get network."$S".ipaddr)

coś takiego ... lub podobne, chodzi o to, że jai interfejs jest IPv6, to mogłoby jakoś to IP wyświetlić:

IP=$(ubus call network.interface status '{"interface":"'$S'"}' 2>/dev/null | jsonfilter -q -e "@['ipv4-address'][0].address")
[ -z "$IP" ] && IP=$(ubus call network.interface status '{"interface":"'$S'"}' 2>/dev/null | jsonfilter -q -e "@['ipv6-address'][0].address")
[ -z "$IP" ] && IP=$(uci -q -P /var/state get network."$S".ipaddr)

U mnie działa...

I takie pytanie: Skonfigurowałem ten tunel testowo i gdybym chciał wyłączyć bez usuwania konfiguracji to robię:

uci set network.henet.disabled="1"
uci commit network
service network reload

a aktywuję ponownie:

uci set network.henet.disabled="0"
uci commit network
service network reload

?

Idź do forum: Oprogramowanie / Software

39 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Przemyślałem co mi się dzieje i kiedy i zrobiłem test, w sumie bardzo prosty:
- odłączyłem router od zasilania
- włączyłem ponownie
- zajrzałem na stronę /overview.sh i w polu "WAN IP Address:" był (jakiś) adres IPv6
- zalogowałem się po SSH
- zrobiłem /etc/init.d/network restart
- zajrzałem ponownie na stronę Status i już było ok

Ale: Zanim zrestartowałem sieć, to sprawdziłem - zarówno router jak i moja maszyna miały połączenie z internetem. Klienci OpenVPN się podłączyli. Polecenie ifconfig podawało prawidłowy adres IP.

Czyli mój wniosek jest taki: Wygląda, że wszystko działało prawidłowo, tylko interfejs Gargoyle nie pokazywał adresu IPv4 przyznanego po podłączeniu przez PPPoE.

Idź do forum: Oprogramowanie / Software

40 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Ad. 1: Tak odświeżyłem i nauczyłem się czytać: "Universal Plug and Play Support for Gargoyle" ?

Ad. 2: Zmiana języka na en i na pl pomogła.

Znalazłem pewien problem w 1.13pre9. Za pierwszym razem go zignorowałem, ale jak po się pojawił po raz kolejny, to uznałem, że może jednak coś jest "nie tak":

Używam połączenia "PPPoE (Wired)". Skonfigurowałem, wyłączyłem router, przeniosłem w miejsce docelowe, podłączyłem kable, włączyłem i ... nie dostałem IPv4. W Status -> WAN -> WAN IP Address było jakieś IPv6. W tym momencie można zrobić reboot z menu (tak zrobiłem za pierwszym razem - Archer C7 v2) albo /etc/init.d/network restart (tak za drugim razem - 1043ND v3) i już działało normalnie. Nie wiem gdzie szukać źródła problemu o ile to nie przypadek, ale było już tak dwa razy, to zdecydowałem się napisać.

Idź do forum: Oprogramowanie / Software

41 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

No właśnie pod latarnią byłem ... i nie ma. Ale jak wejdę po SSH to się pojawia smile

A co do instalacji i używania ... faktycznie nie zamierzam, bo jednak wolę sam sobie porty przekierować.
Ale tak teraz się zastanawiam: Dałoby się tą funkcjonalność wykorzystać w taki sposób, że odpalasz aplikację, patrzysz co sobie przekierowała i następnie robisz te przekierowania ręcznie?

BTW: Osobiście używam wersji angielskiej interfejsu, ale bratu zostawiłem polską i po zainstalowaniu "Services Manager for Gargoyle" i zamiast "Usługi" (tak było we wcześniejszych wersjach) jest ciągle "Services".

Idź do forum: Oprogramowanie / Software

42 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

BTW: "Wymagana jest instalacja dodatkowego pakietu aby skorzystać z tej opcji!" przy UPnP / NAT-PMP - jakiego pakietu brakuje?

Idź do forum: Oprogramowanie / Software

43 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Właśnie rozpakowałem nowy router, skonfigurowałem, sprawdziłem i miałem wysłać zgłoszenie i ... widzę, że już zgłosiłeś smile

Jak chodzi o moje testy problem występuje tylko po TCP, pod UDP nie miałem zduplikowanych linii.

Idź do forum: Oprogramowanie / Software

44 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Po co zmiany w /etc/openvpn.firewall - bo mi błędy wyświetliło przy restarcie firewalla, więc szukałem gdzie są, żeby ich nie wyświetlało.

Po co to jest, nie wiem - miałem i nie ruszałem tego wpisu w /etc/config/firewall:

config include 'openvpn_include_file'
        option path '/etc/openvpn.firewall'
        option reload '1'

A co do netstata, jest też -u i wyświetla zarówno tcp jak i udp (w skrócie wygląda to tak):

root@gate:~# netstat -u -t -p -a -e -n
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1700/dropbear
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      2281/uhttpd
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      6102/openvpn
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1856/rpcbind
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2281/uhttpd
tcp        0      0 172.16.32.1:53          0.0.0.0:*               LISTEN      2829/dnsmasq
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2829/dnsmasq
tcp        0      0 192.168.32.1:53         0.0.0.0:*               LISTEN      2829/dnsmasq
tcp        0      0 111.22.33.144:1194      115.16.171.8:16734      ESTABLISHED 6102/openvpn
tcp        0      0 192.168.32.1:22         192.168.32.21:51647     ESTABLISHED 13727/dropbear
tcp        0      0 :::22                   :::*                    LISTEN      1700/dropbear
tcp        0      0 :::443                  :::*                    LISTEN      2281/uhttpd
tcp        0      0 :::111                  :::*                    LISTEN      1856/rpcbind
tcp        0      0 :::80                   :::*                    LISTEN      2281/uhttpd
tcp        0      0 ::1:53                  :::*                    LISTEN      2829/dnsmasq
udp        0      0 0.0.0.0:67              0.0.0.0:*                           2829/dnsmasq
udp        0      0 0.0.0.0:65113           0.0.0.0:*                           1856/rpcbind
udp        0      0 0.0.0.0:111             0.0.0.0:*                           1856/rpcbind
udp        0      0 172.16.32.1:53          0.0.0.0:*                           2829/dnsmasq
udp        0      0 127.0.0.1:53            0.0.0.0:*                           2829/dnsmasq
udp        0      0 192.168.32.1:53         0.0.0.0:*                           2829/dnsmasq

Idź do forum: Oprogramowanie / Software

45 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Zrobiłem to, żeby mi nie sypało błędami przy restarcie firewalla, a co te dwie linie dokładnie robią to nie próbowałem dochodzić.

A pomijając celowość poprawki, to wykrywanie protokołu i portu na którym działa OpenVPN działa poprawnie, dopóki nie podłączą się klienci (do tego czasu jest tylko jedna linia powiązana z openvpn w wynikach netstata). Jak klienci są online, to sypie takimi błędami jak powyżej.

Ale... Moje rozwiązanie też nie jest dobre. U mnie, po TCP jest ok, ale jak się serwer uruchomi na UDP, to nie ma "LISTEN". Może "grep 0.0.0.0"?

Idź do forum: Oprogramowanie / Software

46 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Jak chodzi o te warningi, to nie wiem o co mu chodzi, ale to na końcu generuje skrypt /etc/openvpn.firewall, a konkretnie te linie:

iptables -t mangle -A INPUT  -i "$wan_if" -p "$openvpn_proto" --dport "$local_openvpn_port" -j openvpn_down_bw
iptables -t mangle -A OUTPUT -o "$wan_if" -p "$openvpn_proto" --sport "$local_openvpn_port" -j openvpn_up_bw

i parametr $openvpn_proto, który określany jest tutaj:

openvpn_proto=$(netstat -u -t -p -a -e -n 2>/dev/null | awk ' $0 ~/openvpn/ { print $1 ; } ')

u mnie to polecenie zwraca:

root@gate:/etc$ netstat -u -t -p -a -e -n 2>/dev/null | awk ' $0 ~/openvpn/ { print $1 ; } '
tcp
tcp
tcp
tcp
tcp
tcp

---------------------------------------------------------------------------------------------------------------------------------------------

Edit:

Jak zamieniłem:

local_openvpn_port=$(netstat -u -t -p -a -e -n 2>/dev/null | awk ' $0 ~/openvpn/ { gsub(/^.*:/, "", $4) ; print $4 ; } ')
openvpn_proto=$(netstat -u -t -p -a -e -n 2>/dev/null | awk ' $0 ~/openvpn/ { print $1 ; } ')

na:

local_openvpn_port=$(netstat -u -t -p -a -e -n 2>/dev/null | grep LISTEN | awk ' $0 ~/openvpn/ { gsub(/^.*:/, "", $4) ; print $4 ; } ')
openvpn_proto=$(netstat -u -t -p -a -e -n 2>/dev/null | grep LISTEN | awk ' $0 ~/openvpn/ { print $1 ; } ')

to przestało sypać błędami.

Idź do forum: Oprogramowanie / Software

47 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

I w ten sposób wszystkie monity, narzekania, ohy i ahy o bezpieczeństwie i znalezionych dziurach są nic nie warte bo użytkownicy i tak mają to gdzieś smile

smile


A tak serio: Gdyby do przejścia na kolejną wersję starczało zrobić "opkg update" i "opkg upgrade", to byłoby łatwej. Przeszedłem z 1.9.2 na 1.13pre9 i ... działa, ale trochę mi zeszło przeniesienie konfiguracji.

Z 1043ND v3 przeniosłem się na Archera C7 v2 ... i jakoś nie jestem przekonany, że dobrze zrobiłem. Przeniosłem regułki firewalla (przekierowania portów) i nagle część mi zniknęła. W /etc/config/firewall na sztuki były wszystkie, ale większość pusta. Przeniosłem ponownie (ręcznie edytując plik), potem zrobiłem: uci commit, /etc/init.d/firewall restart i poza resztą wyglądającą poprawnie wyskoczyło:

 * Populating IPv6 nat table
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_vpn_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'
   * Zone 'lan'
   * Zone 'wan'
   * Zone 'vpn'

a na koniec:

 * Running script '/etc/firewall.user'
 * Running script '/usr/lib/gargoyle_firewall_util/gargoyle_additions.firewall'
 * Running script '/etc/openvpn.firewall'
iptables v1.8.3 (legacy): unknown protocol "tcp
tcp
tcp
tcp
tcp
tcp" specified
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.3 (legacy): unknown protocol "tcp
tcp
tcp
tcp
tcp
tcp" specified
Try `iptables -h' or 'iptables --help' for more information.

i jeszcze na początku:

Warning: Unable to locate ipset utility, disabling ipset support
Warning: Section 'redirect_enabled_number_0' has no target specified, defaulting to DNAT
Warning: Section 'redirect_enabled_number_1' has no target specified, defaulting to DNAT

itd. dla wszystkich regułek przekierowań.

Idź do forum: Oprogramowanie / Software

48 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Ehhh... Może i starej, ale:

Uptime: 380 days, 21 hours, 26 minutes

Z tym nic się nie dzieje. Nawet po wymianie kabla ethernetowego od dostawcy na GPONa nie restartowałem urządzenia. Gdyby nie to ograniczenie szybkości, to dalej bym nie ruszał wink

Idź do forum: Oprogramowanie / Software

49 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Zakładam optymistycznie, że certyfikaty da radę skopiować, a resztę jakoś ogarnę. Żyję nadzieją, że uda mi się uniknąć konfigurowania klientów ... odetnie mnie od nich, jak się nie połączy OpenVPN hmm

Statystyki z bwmona i webmona da radę przenieść? Skopiowanie zawartości katalogu /usr/data wystarczy?

Idź do forum: Oprogramowanie / Software

50 Odpowiedź przez marcinkk

(592 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

- nie możesz odtwarzać backupu  z innych modeli. A w szczególności nie możesz przenosić plików network i wireless, system też może być inny, pewnie parę innych jeszcze by się zalazło. Inne pliki (jak firewall, qos) możesz przenieść

OK. Ale to i tak wiele ułatwi, że pojedyncze pliki, czy nawet sekcje mogę przenieść korzystając z połączenia SSH smile

Aktualnie mam więcej roboty. DHCP w 1.9.2 zdaje się korzystało z plików /etc/ethers i /etc/hosts, w 1.13 wszystko jest w /etc/config/dhcp i przenosiłem ręcznie ... aczkolwiek pod koniec (miałem kilka wpisów ręcznych) zobaczyłem opcję "option readethers '1'" w starym configu, może jednak dało się skopiować te dwa pliki?

W OpenVPN dużo różnic jest pomiędzy 1.9.2 a 1.13? Mam szansę jakoś szybko ogarnąć przeniesienie?

Idź do forum: Oprogramowanie / Software