1

(0 odpowiedzi, napisanych Oprogramowanie / Software)

Witajcie,

Chciałbym się podzielić moim rozwiązaniem dotyczącym wymuszenia restartu modemu LTE.

Mój modem to Huawei E3276.

Niestety co jakiś czas zdarza się, że modem traci połączenie z internetem. Nie udało mi się ustalić przyczyny, ale dzieje się to stosunkowo rzadko (raz na kilka dni).
Jest to o tyle kłopotliwe, że modem ten stanowi dla mnie backup głównego łącza ethernetowego (przełączanie następuje za pomocą mwan3) i musi znajdować się stale w stanie gotowości.

Mój "workaround" to badanie pingiem czy działa internet (8.8.8.8) poprzez interfejs modemu (wan2).
Jeśli nie, to wymuszam restart modemu.
Testowanie odbywa się co 30 minut (skrypt odpalany w cronie)

Niestety nie sprawdza się prosty sposób restartu w postaci:

ifdown wan2
ifup wan2

Po tym zabiegu mój modem dalej nie jest połączony z internetem.

Ja do restartu używam toola "usbreset" (trzeba doinstalować pakiet usbreset)

ifdown wan2
usbreset  xxxx:yyyy
ifup wan2

xxxx:yyyy - znajdujemy za pomocą lsusb (z pakietu usbutils)

A całe rozwiązanie wygląda tak:

- skrypt monitorujący połączenie: 
lte_connection_monitor

#!/bin/ash
# skrypt do monitorowania polaczenia LTE z crona
# jesli ping przez interfejs wan2/wwan0 (modem LTE) nie dziala
# to nastepuje restart modemu LTE
#
# dodatkowo kazdy restart jest logowany do pliku

# zmienna "modem_status" - przechowuje wynik pingowania hosta w internecie przez inrefejs LTE
# 1 - oznacza ze link dziala
# 0 - link nie dziala
modem_status=1;
modem_status=`ping 8.8.8.8 -I wwan0 -c 5 -w 5 2> /dev/null | grep -c "\ 0% packet loss"` ;
if [ $modem_status == 0  ]; then
    # logowanie restartu do pliku
    date >> /tmp/ubi1/lte_restart.log;
    # restart modemu
    /root/bin/lte_modem_restart >> /dev/null
fi

- skrypt restartujący modem LTE:
lte_modem_restart

#!/bin/ash
ifdown wan2
usbreset  xxxx:yyyy
ifup wan2

- wywolanie w cronie (co 30 minut):

*/30 * * * * /root/bin/lte_connection_monitor
Cezary napisał/a:

Źle interpretujesz. To jest skrypt który wykonuje się raz przy pierwszym starcie systemu żeby przepisać stare opcje na nowe. I nigdy więcej nie jest używany. Jak byś miał obraz który miałby wkompilowanego mwan3 ze starym opcjami (lub zrobił aktualizację z zachowaniem konfigów) to ten skrypt by zadziałał i przepisał to always na ifup/ifdown.

Teraz rozumiem.

Dzięki za pomoc !

Cezary napisał/a:

Bo to się nie nazywa always smile

https://github.com/openwrt/packages/blo … _conntrack

dodaj sobie, zrestartuj itd:

list flush_conntrack ifup
list flush_conntrack ifdown

Masz rację, po dodaniu w konfiguracji interfejsów:
list flush_conntrack ifup
list flush_conntrack ifdown
tablica połączeń jest czyszczona. Dzięki !

Niemniej jednak, w definicji tej funkcji:
https://github.com/openwrt/packages/blo … _conntrack
Widzę opcję 'never' i 'always'.
Ale może coś źle interpretuję.

Pozdrawiam

Cezary napisał/a:

1. Tak działa mwan3, sesyjnie, od zawsze. Nie przerzuci aktywnej sesji na inne łącze po jego zmianie. Zawsze pisali że trzeba samemu zerwać sesję.
2. zrób ręcznie echo f > /proc/net/nf_conntrack i zobacz czy ci to działa. Dokładnie to robi mwan3.

po zrobieniu
echo f > /proc/net/nf_conntrack
działa to poprawnie (sesje są zrywane).

Ale chyba:
echo f > /proc/net/nf_conntrack
robi to samo co: conntrack -F ?

Dziwi mnie, że nie działa opcja:
option flush_conntrack 'always'
w konfiguracji interfejsu w /etc/config/mwan3
Na logikę powinno to rozwiązywać problem.

Aha, zauważyłem, że jeśli ręcznie wymuszam restart demona mwan3 to dostaje komunikat:
"WARN : Service section disabled! - TERMINATE"

Nie wiem czy ma to jakikolwiek związek z w/w zachowaniem.

Pozdrawiam
Krzysztof

Witajcie,

Podczas konfigurowania mwan3 dla aranżacji:
- główne łącze eth
- backup po LTE
natrafiłem na problem utrzymywanie przez router aktywnych sesji sieciowych (poprzez stare łącze).

Praktyczny przykład:
na kompie z windowsem podłączonym do routera mam ustawiony ciągły ping do 1.1.1.1
na routerze wymuszam przełączenie na backup po LTE (np. poprzez wyjęcie eth z głównego łącza).
po 30 sekundach (w mojej konfiguracji) łącze przeskakuje na LTE, ale pingi do 1.1.1.1 w windowsie cały czas są dropowane (bo router trzyma starą tablicę połączeń).
Wszelkie nowe połączenia z windowsa działają OK.

Ta sama sytuacja występuje w drugą stronę, tzn. powrotu z LTE na główne łącze. Aktywne sesje zostają na backupie.
(to jest mniej dotkliwe bo jednak połączenie sieciowe działa. Problemem może tu być zużywanie limitu LTE).

Rozwiązanie jakie znalazłem to wymuszenie wyczyszczenia tablicy połączeń poprzez:

conntrack -F 

(konieczna instalacja pakietu "conntrack")

Żeby to działało automatycznie umieściłem to w skrypcie:
/etc/mwan3.user:

if [ "$ACTION" == "disconnected" ]; then
  /usr/sbin/conntrack -F
fi

if [ "$ACTION" == "connected" ]; then
  /usr/sbin/conntrack -F
fi

Co ciekawe znalazłem opcję w konfiguracji mwan3 (w pliku /etc/config/mwan3), która teoretycznie powinna rozwiazywać ten problem.
Chodzi o:
option flush_conntrack 'always'

Tutaj cala konfiguracja interfejsu "wan":

config interface 'wan'
        option enabled '1'
        list track_ip '8.8.4.4'
        option family 'ipv4'
        option reliability '2'
        option count '1'
        option timeout '2'
        option failure_latency '1000'
        option recovery_latency '500'
        option failure_loss '20'
        option recovery_loss '5'
        option interval '5'
        option down '3'
        option up '8'
        option flush_conntrack 'always'

Ale z jakiegoś powodu to nie działa. Dlatego musiałem zrobić to w skrypcie.

Może komuś się przyda.

No i w sumie jestem ciekaw 2 rzeczy:
- nie widziałem opisu tego problemu przy omawianiu konfiguracji mwan3. Czyżbym tylko ja miał problem z czyszczeniem aktywnych sesji?
- czemu nie działa opcja: option flush_conntrack 'always' ?

Pozdrawiam
Krzysztof

P.S.
Moje wersja pakietu mwan3: 2.8.13-1

6

(6 odpowiedzi, napisanych Oprogramowanie / Software)

Upgreydd napisał/a:

skrypt bash i przez telnet może? wink

Niestety, dostęp do Funboxa jest możliwy tylko poprzez https.

7

(6 odpowiedzi, napisanych Oprogramowanie / Software)

itias napisał/a:

Zobacz taki skrypt w php z curl: https://code.google.com/p/liveboxreconn … n2&r=2
i spróbuj go dostosować do swojego Livebox'a.


Dzięki,

Oblookam w wolnej chwili.

Pzdr
Krzych

Witam,

Mam następujący problem: chciałbym żeby watchdog w Gargoylu automatycznie restartował Funboxa neostrady w przypadku braku dostępu do Internetu (niestety moja neostrada działa niestabilnie i zdarza się, że połączenie jest dropowane i pomaga tylko restart Funboxa).

Problemem jest to, że Funbox nie posiada CLI i jest do niego dostęp tylko przez WWW:

PunBB bbcode Funbox


Chodzi o to żeby skrypt zasymulował kliknięcie w przycisk "TAK" i zrestartował Funboxa.

Czy jest sposób żeby jakoś to zrealizować?

Pzdr
Krzych

9

(28 odpowiedzi, napisanych Oprogramowanie / Software)

build000 napisał/a:

To nie chodzi o paranoję - po prostu z pewnymi softami nie robi się nic poważnego, bo zawsze się kończy tak samo - w przypadku dropbear na openwrt właśnie tak jest.

W przypadku takich obaw poszedłbym w stronę:
- knockd
lub już super "sekjurnie":
- Single Packet Authorization (fwknop)

Pzdr
Krzych

10

(28 odpowiedzi, napisanych Oprogramowanie / Software)

itias napisał/a:

Może to właściwość putty, którym wytwarzam tunel. Poeksperymentuję trochę i dam znać, może komuś jeszcze się to przyda.

Aktualizacja: faktycznie wygląda to na jakieś kwestie związane z putty. Otwarcie tunelu przez ssh robi dokładnie to co trzeba, czyli można ograniczyć nasłuchiwanie do określonego interfejsu.

Pobawiłem się chwilę puttym i wygląda na to, że musi być włączona opcja Port forwarding  -> remote ports żeby serwer słuchał na innych interfejsach niż 127.0.0.1:

putty

Niestety nie można tego ograniczyć to konretnego intefejsu i odpowiada to unixowemu:

ssh -f -NT -R 0.0.0.0:4445:localhost:22 IP_servera_SSH

Na pewno rozwiązaniem dla klienta windowsowego jest użycie cygwina i polecenia:

ssh -f -NT -R 192.168.1.1:4445:localhost:22 IP_servera_SSH

Pzdr
Krzych

11

(28 odpowiedzi, napisanych Oprogramowanie / Software)

itias napisał/a:

Faktycznie GatewayPorts musi być "on". Co prawda mam efekt uboczny, teraz niezależnie co podam, czy localhost, czy interfejs LAN, słucha na wszystkich interfejsach:

root@xxx:~# netstat -na | grep 4666
tcp        0      0 0.0.0.0:4666            0.0.0.0:*               LISTEN

To dziwne. U mnie słucha wyłącznie na podanym interfejsie.

Na kliencie wywołuję:

root@Gargoyle:~# ssh -f -NT -R 192.168.1.22:4445:localhost:22 192.168.1.2

A na serwerze mam dwa interfejsy:
192.168.1.2 i 192.168.1.22 (secondary IP na LANie):

root@gargoyle2:~# netstat -taupen | grep 4445
tcp        0      0 192.168.1.22:4445       0.0.0.0:*               LISTEN      2622/dropbear
root@gargoyle2:~#
root@gargoyle2:~# telnet 127.0.0.1 4445
telnet: can't connect to remote host (127.0.0.1): Connection refused
root@gargoyle2:~#
root@gargoyle2:~# telnet 192.168.1.2 4445
telnet: can't connect to remote host (192.168.1.2): Connection refused
root@gargoyle2:~#
root@gargoyle2:~# telnet 192.168.1.22 4445
SSH-2.0-dropbear_2014.65

jak widać nawet na localhoscie nie słucha.

Pzdr
Krzych

12

(28 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

Ha, W AA działało, a teraz inaczej są weryfikowane parametry ...

Ja tam nie wiem, swieżonka jestem w Gargoylu ;-)

Btw, szkoda, że w twoich tutorialach nie można dodawać komentarzy. Byłoby łatwiej wyłapywać takie rzeczy.

Pzdr
Krzych

13

(28 odpowiedzi, napisanych Oprogramowanie / Software)

itias napisał/a:

Krzychu, dzięki wielkie. Jutro przetestuję w firmie, którą się opiekuję, bardzo mi to ułatwi sprawę zdalnego monitorowania.

Mam nadzieję, że Ci to zadziała.

Przy okazji jeszcze jedna uwaga. Na moim Gargoyl'u

 | Gargoyle PL 1.6.2.2 (b70bfc1)                                |
 | OpenWrt Attitude Adjustment 12.09.1 (r42647)                 |

nie działa opcja:

uci set dropbear.@dropbear[0].SSHKeepAlive=XX

odpowiada ona za zabicie martwej sesji ssh. (Parametr -K demona dropbear):

-K <keepalive>  (0 is never, default 0, in seconds)

gdzieś czytałem, że domyślna wartość to 300s, ale jak widać powyżej nie jest to prawda. Martwa sesja nigdy domyślnie nie wygasa (robiłem testy i po około 30 minutach sesja dalej wisiała).

U mnie jest to istotna sprawa, bo serwer, z którym się łaczę ma zmienny adress IP (Neostrada). Łączę się używając DDNSa a nie adresu IP. Więc zależy mi żeby po zmianie IPka serwer zabił nieaktywną sesję ssh. W przeciwnym razie klient zobaczy cos takiego:

root@Gargoyle:~# ssh: Remote TCP forward request failed (port 4445 -> localhost:22)

Żeby opcja "SSHKeepAlive" zaczęła u mnie działać zmodyfikowałem plik:

/etc/init.d/dropbear

W linii 84 dopisałem:

        # H) SSHKeepAlive
        config_get val "${section}" SSHKeepAlive
        [ "${val}" ] && append args "-K ${val}"

teraz po ustawieniu w pliku konfiguracyjnym (lub za pomocą UCI):

/etc/config/dropbear:
        option SSHKeepAlive '10'

martwa sesja jest zabijana po 10s. A demon odpala się z opcją -K:

 3180 root      1164 S    /usr/sbin/dropbear -P /var/run/dropbear.2.pid -p 4444 -a -K 10

Pzdr
Krzych

14

(28 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary napisał/a:

W sensie?  GatewayPorts  jest czytany boolem, więc reaguje na on/off/1/0/yes/no

Zobacz:

root@Gargoyle:~# uci set dropbear.global.GatewayPorts=yes
root@Gargoyle:~# uci commit dropbear
root@Gargoyle:~# /etc/init.d/dropbear restart
root@Gargoyle:~# ps | grep drop
 3382 root      1256 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a
 4014 root      1164 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22
 4016 root      1496 S    grep drop
root@Gargoyle:~#
root@Gargoyle:~# uci set dropbear.global.GatewayPorts=on
root@Gargoyle:~# uci commit dropbear
root@Gargoyle:~# /etc/init.d/dropbear restart
root@Gargoyle:~# ps | grep drop
 3382 root      1256 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a
 4035 root      1164 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a
 4037 root      1496 S    grep drop

Proces 3382 to bieżaca sesja ssh więc nie jest restartowana.

Pzdr
Krzych

15

(28 odpowiedzi, napisanych Oprogramowanie / Software)

itias napisał/a:

Potrzebowałem ostatnio za pomocą SSH otworzyć odwrotny tunel z zewnątrz do mojego routera. Niestety nie potrafię tego zrobić, a raczej potrafię, ale na routerze port jest otwarty tylko dla localhosta, a nie dla wszystkich po stronie LAN:

root@xxx:~# netstat -na | grep 466
tcp        0      0 127.0.0.1:4666          0.0.0.0:*               LISTEN

Uprzednio zmieniłem konfigurację dropbear'a włączając GatewayPorts i w tej chwili mam w /etc/config/dropbear

config 'dropbear'
        option 'PasswordAuth' 'on'
        option 'Port' '22'
        option 'GatewayPorts' 'yes'

Hej,

Własnie walczyłem z tym samym problemem.

Wygląda na to, że w tutorialu Cezarego jest błąd: http://eko.one.pl/?p=openwrt-sshtunnel
Prawidłowa opcja do odblokowania forwardowania portów w pliku /etc/config/dropbear to:

        option GatewayPorts 'on'

możesz to zweryfikować patrząc na procesy:

 ps | grep drop
 3083 root      1232 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a

jeśli parametr -a jest obecny to opcja jest aktywna
(-a              Allow connections to forwarded ports from any host)

Dodatkowo demon dropbear działa trochę inaczej niż inne unixowe sshd i domyślnie nasłuchuje tylko na 127.0.0.1.

Żeby to zmienić musisz przy tworzeniu reverse tunelu od strony klienta wskazać konkretny interfejs na serwerze.

Czyli zamiast:

ssh -f -NT -R 4445:localhost:22 192.168.1.2

Wywołujesz:

ssh -f -NT -R 192.168.1.2:4445:localhost:22 192.168.1.2 

lub bardziej ogólnie:

ssh -f -NT -R 0.0.0.0:4445:localhost:22 192.168.1.2 

(wtedy serwer słuch na wszystkich interfejsach - czyli działa tak jak inne demony sshd).

Pzdr
Krzych