Trochę namieszałem pod koniec z firewall, DNS, route. Nie jestem pewien czy kolejność restartów jest dobra. Jest to opis do startu z 'palca' - dlatego tak wyszło.

Odnośnie paczki. Użyte moduły są z różnych kompilacji i zasobów. Skoro działają, to chyba nie przeszkadza?

Wysłałem na Twojego maila paczuszkę z plikami

Chyba masz rację. Więc prośba. Wywal z paczki KQD... i ZZZ... , a w opisie podam sposób pobrania firmware ze strony Sppedtoucha.

Witaj Cezary,

Wracam jeszcze do tematu neo.
Zaobserwowałem, że kilka razy router stracił połączenie przez ppp0. Najprawdopodobniej dzieje się tak przy zmianie nr IP przez ISP.
Jest jeszcze jedna możliwość. Po odpaleniu routera, zostawiałem włączonego kompa z odpalownym Webif do rutera. Gdzieś czytałem (ale nie jestem pewien czy o to chodziło), że pozostawienie aktywnego Webif powoduje zamulenie routera. Może to jest powodem.
Będę musiał pokombinować (dokładnie posprawdzać).

W związku z tym, żeby mieć wgląd w to co się dzieje routerze z dowolnego miejsca, chciałbym otworzyć firewall od stony WAN na możliwość połączenia po SSL (chyba port 22). Oczywiście tylko tymczasowo, do testów. Nie bardzo wiem jak powinien wyglądać wpis ustawienia firewalla. Możesz mi pomóc?

Pozdrawiam Jarek

Witam,

Po otwarciu portu 22 na WAN zauważyłem (w logach) nieautoryzowane próby logowania się do routera. Czy to normalna rzecz? A.... zaponiałem dodać że uruchomiłem DynDNS na DynDNS.org. Może przez to dotępny jest mój IP w necie i są próby włamów?

EDIT:
Dostęp z zewnątrz oczywiście działa.

Czały czas staram się rozwiązać problem z podnoszeniem ppp0 po zmianie IP przez ISP.

Mam pewien pomysł. Zauważyłem, że w momencie padu ppp0 jest uruchamiany skrypt /etc/ppp/ip-down, a ten może odpalić skrypt użytkownika (odpalanie jest wbudowane) z katalogu /etc/ppp/ip-down.d , należy tam tylko umieścić własny skrypt o nazwie ppp0. Podobna sytuacja jest przy podnoszeniu połączenia. Automatycznie daje możliwość uruchomić skrypt użytkownika /etc/ppp/ip-up.d/ppp0. Pomysł jest następujący:

1. Kiedy pada połączenie odpala się mój skrypt /etc/ppp/ip-down.d/ppp0 (będę go tu nazywał IPDN), a w nim:
- zabić proces pppd
- odpalić cron - co 15 sekund uruchamiający IPDN
- odpalić pppd w celu nawiązania połączenia ppp0

2. Jeżeli po kilku próbach pppd nie podniesie ppp0, to kron odpali IPDN i ponowi próbę

3. Jeśli ppp0 zostanie ustanowione, to automat uruchomi mój skrypt /etc/ppp/ip-up.d/ppp0 (tu go nazwę IPUP), a w nim:
- zabić proces cron z podtrzymaniem wywołania IPDN
- ....... odpalić wszystkie programy potrzebujące aktualizacji z nowym IP (np. DynDNS, itp)

Co o tym sądzisz? Czy widzisz w tym jakieś słabe punkty?

Jarek

Niestety następuje rozłączenie ppp0 i pppd róbuje je nawiązać ponownie. Po kilkunastu próbach (ilość prób jest zdefiniowana w skrypcie do pppoa3 - u mnie /etc/ppp/peers/neostrada-pppoa, ilość prób zdefiniowana na 15 i przerwy między próbami 3 sek, czyli daje to 45 sekund na próby podniesienia ppp0) pppd nie nawiązując połączenia (u mnie jeśli nie złapał za 1 razem to kolejne nic nie dają) kończy soje działanie i wszystko stoi. Trzeba go odpalić ponownie pppd.
Na samym początku prób nawet przy żle ustawionych iptables i dnsmasq, pppd ustanawiał połączenie ppp0. Więc myslę, że restart iptables/dnsmasq nie pomoże podnieść ppp0.

Znalazłem jeszcze jedną powtarzającą się rzecz przy zakańczaniu ppp0.

Mianowicie w syslog jest raportowany stan pppd. Poniżej raport z 2 różnych syslog.
Syslog1

...
Jan  2 01:01:09 (none) kern.debug pppd[726]: rcvd [LCP TermReq id=0x75]
Jan  2 01:01:09 (none) kern.info pppd[726]: LCP terminated by peer
Jan  2 01:01:09 (none) kern.info pppd[726]: Connect time 1440.1 minutes.
Jan  2 01:01:09 (none) kern.info pppd[726]: Sent 92501046 bytes, received 249604728 bytes.
...

Syslog2

...
Jan 26 00:04:29 (none) kern.debug pppd[839]: rcvd [LCP TermReq id=0xea]
Jan 26 00:04:29 (none) kern.info pppd[839]: LCP terminated by peer
Jan 26 00:04:29 (none) kern.info pppd[839]: Connect time 1440.1 minutes.
Jan 26 00:04:29 (none) kern.info pppd[839]: Sent 97000695 bytes, received 161423441 bytes.
...

W obu przypadkoch rozłączenie następuje dokładnie po 1440.1 sekundach, czyli po 24h. Ponadto "pppd[839]: LCP terminated by peer" mówi raczej, że połączenie zostało przerwane przez użytkownika?!?!?!?!

Może problem leży w skrypcie dla pppoa3, gdzie są podane różne ustawienia? Ale nie widzę tam żadnego ustawienia do czasu trwania aktywnego połączenia. Poniżej zawartość skryptu dla pppoa3:

debug
kdebug 1
lock
noipdefault
defaultroute
pty "/usr/local/pppoa3 -v 1 -e 1 -c -m 1 -vpi 0 -vci 35"
asyncmap 0
lcp-echo-interval  2
lcp-echo-failure   7
sync
user XYXYXYX@neostrada.pl
noauth
holdoff 3
persist
maxfail 15
mru 1500
mtu 1500

Co o tym myślisz?

Jarek

Witaj Cezary,

Pierwsze podejście z użyciem skryptów automatycznych /etc/ppp/ip-down.d/ppp0 i /etc/ppp/ip-up.d/ppp0 nie wyszło.
Umieszczone w /etc/ppp/ip-down.d/ppp0 polecenie 'pppd call neostrada-pppoa' nie uruchamia pppd?!?!?! Nie bardzo wiem dlaczego, ale na razie nie będę w to wnikał. Zmodyfikowałem koncepcję. Muszę się skoncentrować nad właściwym ustawieniem crona. I znów kilka pytań.

1. Czy kron może uruchamiać program częściej niż co minutę? Np co 15s.?
2. Czy mógłbyś sprawdzić u siebie co zawiera plik /etc/crontabs/root? Ja mam w nim straszny śmietnik! A wydaje mi się że tam powinny być wpisy konf dla crona. U mnie zawiera:

.0 TZ dhcp.leases log net resolv.conf resolv.conf.auto run spool usr TZ dhcp.leases log net resolv.conf resolv.conf.auto run spool usr TZ dhcp.leases log net resolv.conf resolv.conf.auto run spool usr TZ dhcp.leases log net resolv.conf resolv.conf.auto run spool usr

Czy aby napewno tak ma być? Jeśli tak to gdzie mają być wpisy konf dla crona?

Pozdrawiam Jarek

EDIT:
Już sobie poradziłe. Wywaliłem starą zawartość i wsadziłem wpisy dla crona. Działa
Zostaje tylko kwestia odpalania częściej niż co 1 min.

Wreszcie mam dopracowany skrypt (sposób) podnoszenia połączenia po zmianie zewnętrznego IP przez ISP. Modem 3 razy zmienił IP i prawidłowo odtworzył połączenie ppp0. Niestety każda próba wymaga odczekania 24h, ponieważ co ten interwał czasu jest zmieniany IP przez opa.
Odczekam jescze 1-2 próby i jeśli test wypadnie prawidłowo dołączę skryp do HOWTO.

Jarek