Widzę Cezary, że jak zwykle stronniczo podchodzisz do tematu swojego koleżki - czyli jak rozumiem wyzywanie mnie od durni (czy zarzucanie kłamstw) kilka postów temu to jest "dopuszczalny limit buractwa dla buraków" ?

Większy pożytek by był z tego Twojego bełkotu jakbyś wykombinował jak obejść ten problem - rzecz jasna programowo...

Nie na tyle i długo, i efektywnie (w praktyce - schematy i swoją wiedzę zachowaj...dla siebie) żeby można wykorzystać (bo po prostu jak nie ma typowego sterowania tym napięciem na usb to człowiek szuka nawet jakichkolwiek błędów, by je wykorzystać w zamierzonym celu...) to do sterowania modemem.
Nie twierdziłem przecież, że odcina je ewidentnie - jeszcze raz podkreślę, że są to jedynie piki i równie dobrze mogą wynikać z lokalnych przesłanek - a to zakłócenia, a to jakieś niedolutowane końcówki/elementy, a to elementy bierne poza tolerancją wykonania/projektu konstrukcyjnego i milion innych powodów, których zwyczajnie nie mam czasu i ochoty odkrywać i wyjaśniać czy to sobie, czy innym.

Ogólnie jest kicha z tym złączem USB w tym routerze w kontekście modemów komórkowych i tyle...co tu więcej rzeźbić.

ext* w openwrt jest po prostu nie do uniknięcia jako odpowiedni system plików na szeroko pojętych nośnikach pamięci masowej - linux to linux, a windows to windows - pora sobie to zakonotować głęboko w berecie...

A po co podłączać ?...no przecież po to masz m.in. sambę albo ftp...kolejne nieporozumienie w logistyce...

http://zyxel.nas-central.org/wiki/FFP-stick
Czy w formie sticka, czy zainstalowany na dysku przez dodanie spreparowanego repo dla danej wersji softu/nasa, to bez różnicy - podstawa to mieć zainstalowany FFP - to w nim są wspomniane programy, które instalują resztę. To jest to co, nazwałem w poprzednich postach jako dodatek do OFW.
Najwyraźniej widać, że po mimo wskazania wszystkich niezbędnych linków nie czytasz uważnie, albo wcale, całej bogatej info/dokumentacji/tematów na ichnich forach, dotyczących tego zagadnienia...

W WNDR4300 jest ten sam problem ze sterowaniem zasilaniem USB - gdyby było po prostu nie istniałby ten problem...i zapewne ten temat na forum.

He...po prostu ustalam detale.

W Orange z kolei mam problem z samym połączeniem co kilka cykli "wł/wył połączenie modemowe o ustalonych h" (stąd potrzeba restartów/resetów/itd. routera/złącza usb - u mnie to tu się wiesza - pomaga wyjęcie i włożenie modemu - to działa zawsze), bo lata mi ten automatyczny ping w cronie co 10 minut, więc tu nie mogę narzekać - jak już połączy to w interesującym mnie okresie 12 godzin ciągle trzyma połączenie i jest ono aktywne (sprawdzane przez kilka miechów).

Tak wracając na chwilę do edycji tego pliku 30-3g to u mnie chyba nie zdałoby to egzaminu bo mam 2 oddzielne interfejsy (wan i wan2), które dają internet w określonych godzinach.
Chyba, że wystarczy zamienić:

(...)
network.wan.device
(...)

na

(...)
network.wan2.device
(...)

po prostu.

No fakt - komenda usbreset i echo dla tej operacji może przybierać różne argumenty (ja akurat podawałem dla E3372) w zależności od modemu - ale to są niuanse, które łatwo wyłapać w praktyce - kwestia żeby to było skuteczne za każdym razem w kontekście wieszających się modemów mobilnych w formie usb-stick podpiętych pod złącze USB...i tu jest właśnie pies pogrzebany.
Permanentnym rozwiązaniem problemu w każdym możliwym przypadku (poza uszkodzeniem BTS-a rzecz jasna i braku jakiegokolwiek zasięgu) jest definitywne odcięcie zasilania od złącza USB w działającym systemie bez konieczności restartu routera...a to jak na razie jest programowo nieosiągalne w WNDR4300 - ułatwiłoby to wiele kwestii.

Jako, że ukazała się wersja 0.3 poprawiająca błąd działania w temacie "openwrt" w LuCI, przy okazji pozwolę sobie na wskazanie lekko niefrasobliwego błędu:

Nie "parmanently" tylko "permanently".

Przy okazji propozycja tłumaczenia wraz z lekką korektą (kosmetyka + opisy propozycji zmian) tego tekstu:

"Access Control pozwala zarządzać dostępem do Internetu dla poszczególnych hostów lokalnych.
Każda reguła określa poszczególny host, któremu użytkownik zablokował dostęp do internetu. Zasady mogą być aktywne na stałe lub przez pewien okres dnia wyrażony w godzinach i minutach, zgodnie z poniższą formą zapisu:
HH:mm
H - godziny (tu nie wiem, bo do tego czasu nie dotrwałem, żeby to sprawdzić, czy godzina jest w formie 12-to, czy 24-godzinnej - w nawiasie właśnie można o tym wspomnieć w jakiej notacji podawane są godziny - przypuszczam, że 24-godzinnej lub takiej jak jest ustawiony zegar systemowy, czyli albo tak, albo to drugie)
m - minuty (tutaj też nie zauważyłem, bo w innym czasie to testowałem, czy z pominięciem znaczącego zera, czy nie - czyli dla okresu od 1-szej do 9-ej minuty danej godziny; to samo się tyczy powyżej samych godzin - też można o tym wspomnieć w nawiasie)."

EDIT: - właśnie doczytałem w źródłach pluginu, że jest używany czas w notacji 24-godzinnej - także można o tym w w/w nawiasie napomknąć oraz znaczące zero jest
            chyba jednak nieistotne.
          - poza tym zastanawiam się czy ten zapis jest jednak poprawny co do minut (w pliku access_control.lua):

(...)
if hh and mm and hh <= 23 and mm <= 60 then
(...)

...chyba powinno być <=59

Tak na szybko co do uhttpd - po prostu stwórz nowy profil podając mu odpowiednie opcje: porty, katalogi, i.t.d. - co i jak na nim pójdzie (jakiego rodzaju strony, jakie silniki, i.t.d.) to już trzeba pozgłębiać deko manuale. Ogólnie można stwierdzić, że nie jest tak uniwersalny i wydajny jak np. apache albo lighttpd - za to mniej zasobożerny (mniej potrafi ale też i mniej wymaga).
Np. tak to się będzie zaczynać:

config uhttpd 'moja strona'
   list listen_http '0.0.0.0:80'
(...)

Tak w ogóle w profilu 'main' radzę Ci zahaszować odniesienia dla ipv6 jak nie używasz, bo się może gryźć z innymi profilami/apkami webowymi - są tam po prostu porty których możesz chcieć użyć inaczej, niż dla 'main' w uhttpd.

dramatyzujesz - po prostu trzeba się przyzwyczaić oraz więcej jest wymaganych działań w konsoli - to prawie ten sam system - w gargulcu był bardziej zmodyfikowany ale to nadal "pod maską" openwrt.