A jak się rozbiera w R6220 obudowę bo nie widzę śrubek a nie chciałbym na dzień dobry pourywać zatrzasków.
Wstępnie przyglądając się wydaje mi się , że są zatrzaski na górnym dekielku.

Cześć,

Pewnie zapytam o podstawy, ale po radzie w innym wątku zainstalowałem na 1043ND Gargoyle 1.13. Okazuje się, że 8MB flasha to już za mało i nie wszystko się zmieściło - brak przede wszystkim modułu do obsługi OpenVPN. Będzie mi potrzebny extroot ... albo C7. I w jednym i w drugim przypadku mam pytanie:

- Jak chodzi o extroota, to moje obserwacje są takie: Konfiguruję urządzenie, wkładam pendrajwa i robię extroota i w po inicjalizacji mam w urządzeniu dokładnie taką sama konfigurację jak przed zrobieniem tej operacji? Chodzi mi o to, żeby urządzenie maksymalnie skonfigurować - przekierowania, ograniczenia na firewallu (trochę tego mam) i mieć działające "prawie wszystko" bez OpenVPN. A następnie dodać pendrajwa i dokończyć. W razie awarii pendrajwa mam po jego wyjęciu użyteczne urządzenie aż zorganizuję nowego.

- Jak chodzi o C7: Czy te 16MB starczy mi na "wszystko"? I czy mogę zrobić backup ustawień na 1.13 na 1043ND a następnie odtworzyć ten backup na C7? Czy konfigurować C7 ręcznie? A z 1043ND na ER-X da się przenieść?

Aktualnie stary router działa na Gargoyle 1.9.2. Zamierzam przygotować nowy egzemplarz z pełną konfiguracją a potem "tylko przełączyć kabelki" (u mnie to trochę skomplikowane...) do nowego urządzenia.

BTW: Czy jak będzie stabilne 1.14, albo kolejne wersje 1.13, to jest szansa, że da radę zrobić upgrade z zachowaniem ustawień?

Pozdrawiam,
Marcin

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

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?

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

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

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ł

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ń.

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.

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"?

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

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ś

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

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