P10TR, czy mogę prosić Cię o wykonanie następujących operacji, na podstawie których myślę, że będę w stanie wstępnie stwierdzić, co dolega Twojemu routerowi:
1. otwórz przeglądarke na adres routera (domyślnie 192.168.2.1), zaloguj się
2. otwórz następujący URL:
http://<adres routera>/debug.asp
w polu które będzie na stronie wpisz report.txt, a następnie Apply/Zastosuj
3. po kilku sekundach zapisz wygenerowany plik
4. otwórz następujący URL:
http://<adres routera>/syscmd.asp
5. w polu System Command wpisz:
/usr/sbin/telnetd -l /bin/ash
a potem kliknij Apply
6. zaloguj się do routera najlepiej używając narzędzia umożliwiającego logowanie do pliku lub skopiowanie ekranu do pliku (np. PUTTY):
telnet <adres routera>
7. włącz logowanie sesji telnet do pliku
8. wykonaj komendę:
date; uptime
9. wykonaj komendę:
tail -f /var/log/security
10. jeśli router zawiesi się, to zrób kroki 2 i 3, zapisz raport do nowego pliku, a następnie zamknij logowanie sesji telnet i przejdź do kroku 12
11. jesli router zrestartuje się, to zamknij logowanie (o ile nie zamknie się samoczynnie na skutek zerwania sesji telnet)
12. zbierz wszystkie logi, skompresuj, np. WinZIPem i wyślij je do mnie na priv
Prawdę powiedziawszy, to co napisałem powyżej powinien dostarczyć każdemu narzekającemu klientowi Edimax i na podstawie logów coś wykombinować. Nie wiem, czy tak robi, ale pewnie nie. Wobec tego jakiś czas temu stwierdziłem, że sprawy można wziąć w swoje ręce i przynajmniej zorientować się, co się dzieje z tym osławionym routerem, którego też jestem właścicielem. Moje testy wykazały, że naprawdę niewielkie poprawki mogłyby znacząco podnieść satysfakcję użytkowania, np. dorobienie testowego pinga, którego negatywny wynik mógłby wymuszać reset zasilania modemu, itp., itd. Dodatkowo pokusiłem się o zrobienie bardzo drobnego tuningu oprogramowania. W tym momencie brak mi czasu, żeby to przetestować (sam firmware mam już gotowy), a ze względu na fakt, że mój router zaczął chodzić jak zegarek szwajcarski, to nie mam też odpowiedniego bodźca do pracy:-)
Gdyby ktoś byłby jeszcze chętny, żeby mi przysłać logi, to śmiało. Nie obiecuję, że coś konkretnego z tego wyniknie - można to zawsze spakować i wysłać do Edimaxa.
Jeszcze jedna sprawa: na czas testu ustawcie hasło do routera na domyślne, bo z tego co pamiętam, to pojawi się w raporcie jawnym tekstem, więc żeby nie było, że ktoś wstawi tam swój login/password do mBanku a później wyśle to w świat:-))) Do WiFi też lepiej coś prostego zastosować. Tak na wszelki wypadek.
[ Dodano: 2012-01-19, 00:37 ]
P10TR, dzięki za logi.
Jeśli chodzi o krok 9., to komenda 'tail -f' pozwala na śledzenie linii dopisywanych do wskazanego pliku. Nie należy jej przerywać, bo z tego co zauważyłem, to w /var/log/security pojawiają się logi z działania skryptów obsługujących router. Na podstawie logów można stwierdzić, co spowodowało na przykład rozłączenie modemu. Także potrzebowałbym logu, który pokryje czas rozłączenia modemu i ewentualnej próby ponowienia połączenia. Ty nacisnąłeś ctrl-c i przerwałeś działanie tej komendy. Następnym razem spróbuj po prostu uruchomić 'tail -f' i zostawić komendę działającą aż do momentu zauważenia kłopotów z routerem.
To, co wydaje mi się istotne, to prawdopodobnie używasz trybu NDIS na modemie, bo u Ciebie jest w syslogu:
Jan 18 20:53:59 (none) user.debug syslog: Debu: buildIfVc: Interface lo Addr: 127.0.0.1, Flags: 0x0049
Jan 18 20:53:59 (none) user.debug syslog: Debu: buildIfVc: Interface br0 Addr: 192.168.1.1, Flags: 0x1043
Jan 18 20:53:59 (none) user.debug syslog: Debu: buildIfVc: Interface eth5 Addr: 93.154.250.55, Flags: 0x1043
oraz:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
93.154.250.49 0.0.0.0 255.255.255.255 UH 0 0 0 eth5
93.154.250.48 0.0.0.0 255.255.255.240 U 0 0 0 eth5
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
0.0.0.0 93.154.250.49 0.0.0.0 UG 0 0 0 eth5
co wskazuje, że używasz interface'u eth5, a według mnie to zachodzi wtedy, gdy jest NDIS (mówi to mi moje doświadczenie ogólne, bo pierwszy modem 3G miałem w ręku w grudniu 2011:-) )
Niestety nie mam E398 dla porównania. Może ktoś z forumowiczów uzywający E398 mógłby przysłać 'Dziennik bezpieczeństwa' dostępny na routerze ze strony www? Dla modemów używających RAS powinno być moim zdaniem coś takiego w syslogu:
Dec 31 17:35:30 (none) user.debug syslog: Debu: buildIfVc: Interface lo Addr: 127.0.0.1, Flags: 0x0049
Dec 31 17:35:30 (none) user.debug syslog: Debu: buildIfVc: Interface br0 Addr: 192.168.2.1, Flags: 0x1043
Dec 31 17:35:30 (none) user.debug syslog: Debu: buildIfVc: Interface ppp4 Addr: 78.30.123.236, Flags: 0x10d1
Jeśli połączenie jest nawiązane przez RAS, to na routerze oznacza to, że do połączenia z siecią IP operatora jest używany protokół PPP (patrz ppp4 w syslogu powyżej). Z kolei do nadzoru stanu PPP jest używany specjalny skrypt, który potrafi (teoretycznie) wznowić połączenie, jeśli jest coś nie tak z PPP. Są tam nawet specjalnie dodane wyjątki do obsługi E398, które resetują USB, co wznawia zestawienie połączenia.
Wg mnie u Ciebie ten skrypt nie jest używany. Nie ma go na liście procesów.
To, co mogę zaproponować, to upewnić się, w jakim trybie chodzi Twój modem. Pamiętam, że jak miałem E398 z CP do testów, to w aplikacji instalowanej z pamięci modemu była możliwość wybrania typu połączenia. Włóż modem do USB komputera i zobacz, co tam masz ustawione. Upewnij się, że masz RAS.
Jeszcze jedno: czy przypadkiem nie używasz Maca? Może dlatego nie masz dostępu do tej aplikacji?
Och jak ja się cieszę że tego LTE jednak nie kupiłem, a było tak blisko. 
Próbowałem robić debug ale niestety zero reakcji.. strona się otwiera, wpisuję komendę lecz plik się już nie generuje. Miałem już wszystkie dostępne firmware. Na przykład na 1.03a obcinało nawet transfer do 50 % ale był nieco stabilniejszy modem. Teraz na 1.03e dokładnie 24 h i mogę w ciemno resetować router przyciskiem / zasilaniem. Niestety chyba jednak firma Edimax nie ma mocy przerobowych by naprawić w/w problemy. Jedyna ich wymówka że u nich wszystko działa. Czy oni uważają że my sobie te historie z palca wysysamy ?