FreshTomato-ARM 2021.5 jest gotowe do pobrania. Więcej info w pierwszym poście

Dotacje motywacyjne są jak zwykle mile widziane!

Super, ale nieśmiało zwracam uwagę że changelog nie uaktualniony

U mnie od wersji 2021.3 przeglądarka się wywraca przy próbie zmiany 1 WAN na cokolwiek innego, też N18U NVRAM czyszczony, na różnych przeglądarkach, trybach incognito itp. błąd jest ten sam. Pisałem o tym jakiś czas temu ale zostało bez echa. W wolnej chwili zrobię upgrade do 2021.5 i sprawdzę czy nadal tak jest.

Zostało bez echa, bo wszystko jest dobrze (tak dla świętego, sprawdziłem ponownie wczoraj).
Pisałem już dziesiątki razy co należy zrobić z przeglądarką (i jaką) i nie będę się powtarzał...

W takim razie nie wiem co za magia się tu odstawia Czyściłem cache w dwóch przeglądarkach, używałem trybu incognito (ten zazwyczaj używa osobnych plików cache) i nic to nie dało. Używałem różnych komputerów i nadal nic, nawet specjalnie dla Ciebie zainstalowałem świeżo Operę, której nie używam i nadal po kliknięciu w dropdownie 2WAN strona się zawiesza. Żeby być na 1000% pewnym odpaliłem nawet GUI poprzez świeżego chroma na świeżym systemie na virtualboxie i nadal jest to samo. Zawsze robię update z czyszczeniem NVRAMu, a błąd jest od wersji 2021.3 i wcześniej nie występował niezależnie od tego czy NVRAM był czyszczony czy nie i czy przeglądarka miała czyszczone cache - sprawdziłem to kilka miesięcy temu robiąc downgrade do 2021.2 chwile po aktualizacji do 2021.3. Temat odpuściłem, bo pożyczyłem mobilny internet i nie potrzebowałem drugiego wanu.

Może to kwestia jakichś konkretnych ustawień w routerze albo na tej zakładce skoro jest drugi user mający identyczny problem? Ja używam PPPoE, w sumie nie sprawdzałem czy na innym konfigu będzie problem.

To pokaż w takim razie więcej tego swojego setupu na basic-network (zamazując wrażliwe dane).
Masz włączone wszystkie dostępne w routerze Wireless? Czy któraś jest wyłączona (w jaki sposób: na basic-network czy na status page?)

PS. i który (dokładnie, nazwa pliku) masz wgrany obraz.

Dziś zrobiłem upgrade do 2021.5. Standardowa procedura w moim przypadku aktualizacji - czyszczenie NVRAM i konfiguracja od zera. Moje przypuszczenia na temat konkretnej konfiguracji okazują się błędne. Jedyną zmianą, którą zrobiłem po pierwszym zalogowaniu do routera to dodanie bridge'a w zakładce VLAN:


Reszta konfiga jest standardowa - taka jaki dostaje się po czyszczeniu NVRAMu.
Po restarcie routera na świeżo wyczyszczonym z ciastek, historii i czego się tylko dało Edge wejście w zakładkę Basic/Network i kliknięcie opcji 2 WAN kończy się zwisem całej strony


Edit: Obraz freshtomato-RT-N18U-ARM_NG-2021.5-AIO-64K-NOSMP.trx

a czy to samo masz na FireFox - edge tak samo jak chrome niby ze bazuja na chromium obie sa warte mniej niz zero. Jak juz chcesz cos podobnego do Edge/ Chrome to pocecam SRWare Iron

ogolnie to jest zasada ze jak cos nie dziala na przegladarce X to sprawdza sie czy to samo jest na Firefox - i dopiero wtedy wiemy czy jest wyzwanie czy nie.

Nawet jeśli to zadziała na Firefox, to wcale nie oznacza że błędu nie ma.

Problemem jest to, że błąd wydaje się występować tylko u kol. KuteK.

Tak jak wspominałem wcześniej sprawdzałem na różnych kompach i przeglądarkach. Sprawdzałem na świeżo zainstalowanej operze i wisiało, teraz na świeżo zainstalowanym firefoxie też wisi:



Nie jestem jedyny - chwilę wyżej kolega qwerty321 wspomniał o identycznym problemie.

Jeżeli to ma pomóc to problem pojawił się w okolicy wersji 2021.1 albo 2021.2 - gdzieś gdzie w changelogu było info o modyfikacjach zakładki basic.

A ja właśnie zauważyłem inny błąd.
Od wieków nie zmieniałem ustawień WiFi, ale dzisiaj postanowiłem to zrobić i zauważyłem że mój Linksys EA6900 dla Radia 5GHz odmawia ustawienia kanału innego niż 36 (sideband lower) lub 44 (upper). Nie ma przy tym znaczenia szerokość pasma - tak samo się dzieje przy 20Mhz jak i przy 40Mhz.
80Mhz można wybrać i po zapisaniu pokazuje że jest 80Mhz (kanał Auto - nie ma wyboru), ale de facto każdy network scanner pokazuje szerokość 40Mhz jedynie. Mimo że sieci sąsiadów wykrywa szerokie na 80Mhz.
W takiej sytuacji mam problem, bo kanały 36 i 44 są u mnie dość mocno obsadzone.
Problem ten nie występuje na drugim routerze - znaczy na WNDR4500 - no ale on jest na Tomato z gałęzi MIPS.

Scalony z 20 sierpnia 2021 14:56:32:
OK... Niewazne - to był zły region ustawiony. Musialem zapomnieć przy którymś apdejcie zmienić.

DualWan też mi się wieszał jak u kolegów wyżej. Ale myślałem że to coś z moim komputerem i odpuściłem temat. Wy po czyszczeniu nvram nie musicie w failsafe dodawać wpisu httpusername? Jeśli nie to jak się logujecie?

Co można zrobić z żałosną wydajnością OpenVPN? Routery RT-N18U, na WAN po 100MBit. Cipher wybrany na AES-128-CBC. Serwer i client na tych routerach. Wydajność tunelu to max 5Mbit. Kompresja wyłączona, obciążenie CPU max 10%.

nic, najnowszy router AX86U (proc 1.8 GHz arm i wspomaganie sprzetowe) wyciaga na OpenVPN 200-250Mbit. OpenVPN dziala na 1 rdzeniu tylko. N18U - 800MHz i brak wspomagania sprzetowego. Jka nic innego N18U nie robi to OpenVPN moze wyciagnie 25-50Mb (nigdy nie testowalem)- zakladajac ze RT-N16 wyciagal 10Mbit.

dual WAN to nie wiem w czym problem ale AsusWRT i RMErlin tez to nie dziala jak powinno tz dziala WAN + USB ale nie WAN + LAN(jako 2 WAN)

No ok, tylko że obciążenie CPU w czasie transferu tych 5MBit/s sięga max 10% więc zapas jest. Router w zasadzie nic innego nie robi poza zbieraniem statystyk i funkcją serwera dhcp i dns. Rozumiem że CPU jest ograniczeniem, ale co innego jakby dobijał do 100%, tutaj tak nie jest. 25MBit byłoby zupełnie wystarczające. Czy PPTP będzie wydajniejsze?

to jest watek developerski wiec raczej nie miejsce na takie pytania - poczytaj sobie w dziale Ubiquiti (EdgeRouter, Unifi) i zmien router

Ok, zatem pytanie o pptp wycofuję. W wątku developerskim chyba można zgłaszać problemy z wydajnością OpenVPN czy problem po czyszczeniu nvram. Zmień router - hmmm, na pewno? Skoro CPU się nudzi? Może warto się temu przyjrzeć skoro nie tylko ja mam taki problem a temat niskiej wydajności mimo braku obciążenia CPU ciągnie się odkąd wrzucono openvpn do Tomato. Tyle że w N18U jest wyjątkowo słabo. Większe prędkości miałem na stareńkim GL1600 z CPU 240MHz.

tutaj masz odpowiedz https://eko.one.pl/forum/viewtopic.ph...p?id=17025
post byl na naszym forum warto uzyc szukania https://openlinksys.info/forum/viewth...d_id=21631
tutaj ktos uzyskal 13Mbit a na ori sofcie 20Mbit wiec to wszystko co sie da. Na alternatywnym sofcie zawsze jest wolniej gdyz nie ma dostepu do nowszego kernela itd.
chesz sprawdzic VPN to podlacz pod router tylko PC, wylacz wi-fi - przeciez w RT-N18U nie ma oddzielnego procka wi-fi itd

Ok, dziękuję za odpowiedź. Zatem niewykorzystanie mocy procesora nie jest błędem tylko właściwością tego rozwiązania? Dziwne to trochę. Choć 13Mbps już by było lepsze niż 5. Chyba że obciążenie CPU jest źle wskazywane. No ogólnie jednak coś jest nie tak z integracją openvpn w Tomato.

PS. Wifi jest wyłączone.

Ale co chcesz "integrować"?
OpenVPN działa w userspace i możesz zapomnieć o większej wydajności na procesorze nawet 1GHz, pamiętając również że nawet na takim RT-AC3200 (którego m.in. posiadam [ovpn max ~45Mbits]) gdzie jest 2x1GHz, wykorzystywany jest i tak jeden rdzeń (pretensje kierować do deweloperów OpenVPN). I jeszcze brak akceleracji sprzętowej AES-NI...

Natomiast jeśli na RT-N18U uzyskujesz 5Mbits max, to na pewno masz włączoną kompresję, która jeszcze bardziej (niepotrzebnie + niebezpiecznie -> poczytaj o CVE na to) obciąża system.

Dużo też zależy od wybranego szyfrowania, ale to wciąż nie jest temat tego wątku.

Kompresja wyłączona. Bez zmian w wydajności niezależnie od tego czy włączona czy wyłączona.

Wiem że to nie temat tego wątku, ale sądziłem że to jest problem z Tomato więc go zgłaszam.



OpenVPN wykorzystuje 1 rdzeń - ok. Tu mam zegar 800MHz, niechby choć 20MBps było....

Scalony z 30 sierpnia 2021 19:15:31:
RX 1.68 Mbit/s
(0.21 MB/s) Avg 3.17 Mbit/s
(0.39 MB/s) Peak 182.65 Mbit/s
(22.30 MB/s) Total 32.66 GB
TX 0.04 Mbit/s
(0.00 MB/s) Avg 0.06 Mbit/s
(0.01 MB/s) Peak 0.07 Mbit/s
(0.01 MB/s) Total 620.47
Statystyki tunelu z ostatnich 24 godzin. Leci tym rsync między serwerami. połączone bez tunelu rsync idzie z pełną prędkością WAN. Ten peak to jakiś błąd.