tomgme napisał/a:

Czy istnieje możliwość filtrowania słów wyszukiwanych w np. google przez moje dzieci?

Jeśli pytasz, czy jak wpiszą w google "sex" to jakiś mechanizm jest im w stanie to zablokować, to odpowiedz brzmi nie. Przynajmniej nie spoza google. Cała wyszukiwarka jest po https, co oznacza że ruch do niej jest szyfrowany i nie dasz rady niczego podejrzeć.

Są inne mechanizmy, bezpośrednio zaimplementowane w google, które można wykorzystać ale to zależy w jakim wieku są to dzieci, bo jak są starsze, to raczej obejdą taką cenzurę. big_smile Bardziej wyrafinowane rozwiązania są przez filtrowanie domen przez serwer DNS, np. OpenDNS. Mechanizm też bardzo prosty do obejścia dla człowieka, który nieco się orientuje w komputerach. big_smile

A co do sprawy czasowego ograniczenia, to bez problemu w iptables można ustawić regułki typu od 22-6 pakiety nie mają być zrzucane na zaporze, czy o jakich godzinach tam człowiek se życzy. Ale ten mechanizm, podobnie jak te powyższe można również bardzo prosto obejść. Także sam widzisz, że to zależy z kim masz do czynienia i komu chcesz blokować net i co dokładnie chcesz blokować. big_smile Każdy przypadek jest inny i raczej nie ma uniwersalnego rozwiązania.

127

(49 odpowiedzi, napisanych Oprogramowanie / Software)

Poczekaj do piątku od 18. big_smile

128

(49 odpowiedzi, napisanych Oprogramowanie / Software)

NIEOFICJALNIE-w zamian w ramach udobruchania nas ponoć w RBM5 mają wprowadzić RWK.

Hmm. big_smile

A co do abonamentu vs prepaid w play, to fakt. W sumie to ciekawe ile osób ma u nich abonament.

129

(49 odpowiedzi, napisanych Oprogramowanie / Software)

jarek7714 napisał/a:

Co do długości trwania promocji-Play wpadł we własną pułapkę, ma setki tysięcy aktywnych kart z tą promocją i nie może wyłączyć z dnia na dzień bez znaczących strat. Przypomnę dla zainteresowanych że ta promocja jest już aktywna od ponad 2,5 roku .

Nie powiedziałbym, że wpadł w jakąkolwiek pułapkę. Weź sobie policz. W mojej wsi mam chyba 3 BTS z LTE od Play. Dajmy na to, że tuż po wprowadzeniu oferty mieli 100 klientów korzystających z tych BTS. Rok później 1000, a za kolejny rok już korzysta, tak średnio licząc z 5-8k ludzi. Infrastruktura jest ciągle ta sama. Ilość ludzi jedynie zmniejsza transfer na osobę. I tak na początku miałeś może 50mbit w szczycie, a teraz masz 1-2 mbit. A jak wyglądają opłaty? Wtedy było 100x 50 zeta co 100 dni, a teraz? big_smile 8000 x 50 co 100 dni. Sam widzisz, że jest pełno ludzi, którym taki net pasuje, np. mi, choć w godzinach 19-21 to yt w >480p nie obejrzę. big_smile Niemniej jednak, strony www działają bez zarzutu. Dlatego Play nie uwali tej usługi, bo by zaraz finansowanie padło drastycznie.

jarek7714 napisał/a:

Kto dziś to kupi! Jak ma w prepaid darmowe LTE w RBM, a u konkurencji taki pakiet będzie miał przy umowach abonamentowych za połowę ceny.

No tylko standardowo tego darmowego LTE się nie da aktywować, tylko trzeba kombinować z przeniesieniem numeru. Może i to nie problem ale ogromna większość ludzi nie wie, że tak można. Lepiej by się nie dowiedzieli, bo wtedy będę musiał chyba z darmowego Aero w szczycie korzystać. big_smile

Cezary napisał/a:

Te tańsze na allegro to nie są 3372 tylko np. 3370 lub modemy sprowadzane z rosji z innych sieci (megafona). Często też nie wiesz jaki mają soft (zwykły czy hilink) ani w której wersji. Jakub przynajmniej opisuje dokładnie z czym masz do czynienia i te modemy są przystosowane na nasz rynek.

Mi się udało kupić e3372s zwykły z logo orange za chyba coś koło 140 zł.

130

(11 odpowiedzi, napisanych Oprogramowanie / Software)

A nie lepiej -m time w iptables?

http://ipset.netfilter.org/iptables-ext … .html#lbCH

W smstools się da to zrobić. Sam skonfigurowałem sobie mechanizm blokowania połączenia po iptables po tym jak zostanie odebrany sms zawierający pewne słowa kluczowe. Ma też zostać wysłany kod USSD z aktywacją lte. Po pomyślnym włączeniu, system ma odblokować net. Dodatkowo powiadomienie o wszystkich tych zdarzeniach ma zostać wysłane na moją komórkę. Także wystarczy napisać sobie prosty skrypt i dodać kilka warunków.

132

(31 odpowiedzi, napisanych Oprogramowanie / Software)

Zobacz to: https://lists.openwrt.org/pipermail/ope … 19937.html

133

(5 odpowiedzi, napisanych Oprogramowanie / Software)

No to zostaną 3 anteny. big_smile

134

(5 odpowiedzi, napisanych Oprogramowanie / Software)

Czyli nie ma co się w to bawić?

Ostatnio natknąłem się na taki wpis http://myopenrouter.com/forum/wnr3500lv2-antenna-mod . Czy tego typu rozwiązanie jest warte zachodu? Jakby nie patrzeć mam 8 takich samych anten, to bym dorzucił do mojego archera 3, by miał 6. big_smile

136

(17 odpowiedzi, napisanych Oprogramowanie / Software)

Nie wiem czemu przestawiło na private. Teraz powinno być ok. big_smile

Poza tym, zrobiłem to w końcu. Zostawiłem samą metrykę i przydzieliło w oparciu o tę wartość, która jest w sekcji lte:

# ip route show
default via 44.11.22.55 dev eth0  proto static  src 44.11.22.11  metric 10
default via 10.136.111.218 dev wwan0  proto static  src 10.136.111.217  metric 100

Tzn w pliku /lib/netifd/proto/ncm.sh dodałem tylko:

proto_config_add_int metric

local device apn auth username password pincode delay mode metric
json_get_vars device apn auth username password pincode delay mode metric


[ -n "$metric" ] && json_add_int metric "$metric"

[ -n "$metric" ] && json_add_int metric "$metric"

Wpisy od peerdns również działają. Czyli coś z tym defaultroute jest nie tak.

137

(17 odpowiedzi, napisanych Oprogramowanie / Software)

Jak wykomentuję te dodane wpisy, to wszystko wraca do normy, czyli chyba nie są one kompatybilne  zbytnio z wcześniejszą wersją. big_smile

138

(17 odpowiedzi, napisanych Oprogramowanie / Software)

Normalnie dodaje, tzn. przed modyfikacją tego pliku. Po modyfikacji, przestało.

139

(17 odpowiedzi, napisanych Oprogramowanie / Software)

Chyba to nie działa tak jak powinno. Z wizualnych doznań, to nie dodaje domyślnej trasy. Nie wiem czy to tak ma być, bo nie mają wpływu na zachowanie te opcje:

 config interface 'lte'
...
        option metric   '100'
        option 'defaultroute' '1'

W sumie to ten plik wygląda teraz tak: http://pastebin.com/iE64TT5a . Coś pochrzaniłem, czy to nie działa samo z siebie? big_smile

140

(17 odpowiedzi, napisanych Oprogramowanie / Software)

No ręcznie próbuję wpisywać. Może jeszcze raz spróbuję, tym razem na tę wersję co jest w CC. big_smile

141

(17 odpowiedzi, napisanych Oprogramowanie / Software)

Próbowałem pobrać paczki comgt i comgt-ncm z https://downloads.openwrt.org/snapshots … /packages/ i do tego nałożyć tego patcha co jest  tu i tu . Niby błędów przy instalacji nie było no i pozmieniałem co trzeba w pliku. No tylko jak chciałem sprawdzić czy to w ogóle działa to przy ifup dostałem:

daemon.notice netifd: lte (9397): ./ncm.sh: eval: line 1: gcom: not found

Chyba jednak tego nie zrobię. big_smile

Próbuję skonfigurować trasę domyślną dla połączenia LTE. Chodzi oczywiście o uruchomienie internetu na dwóch ISP. W przypadku zwykłych połączeń przewodowych, to nie ma problemu z ustawieniem metryki przez plik /etc/config/network . Wystarczy w sekcji z interfejsem dopisać:

config interface 'wan'
        option ifname   'eth0'
        option metric   '10'
        ...

Niemniej jednak w sekcji lte już za bardzo ten wpis od metryki nie działa. Tak ona obecnie wygląda:

config interface 'lte'
        option ifname   'wwan0'
        option metric   '100'
        option proto    'ncm'
        option mode     'lte'
        option apn      'internet'
        option device   '/dev/ttyUSB0'
        option username ''
        option password ''
        option peerdns  '0'
#      option pppd_options ''

To jak ustawić mu metrykę?

BTW do tego -p icmp dodaj typ, by przepuszczać i limitować tylko pingi.

Co do ! -i br-lan, hmm to pewnie ostatecznie można by tak zrobić.

Też się zastanawiałem jak to będzie wyglądać w kwestii kilku interfejsów WAN. Póki co nie wiem. Może niedługo sprawdzę jak to wygląda ale raczej wątpię, że to tak się da zrobić. Podobnie masz przy logowaniu via ssh jak masz 2 interfejsy WAN, tj. pokazuje tylko jeden, ten główny.

Jak umieszczasz reguły w /etc/firewall.user , to jeśli chcesz okroić je to tylko do interfejsu WAN, to zwykle wystarczy umieścić je w odpowiednim łańcuchu, w tym przypadku zone_wan_input i to zwykle wystarcza, bo ten łańcuch już ma zdefiniowany interfejs WAN dynamicznie i nie trzeba go określać w regułach iptables. Tylko ten łańcuch jest przetwarzany po ESTABLISHED,RELATED i dlatego nie da rady w nim limitować ilości żądań ping. Można to robić przez łańcuch input_rule ale on z kolei nie ma przypisanego interfejsu i jeśli bym przykładowo dodał w nim takie regułki:

iptables -t filter -A input_rule -p icmp --icmp-type echo-request  -m limit --limit 50/s --limit-burst 100 -j ACCEPT -m comment --comment "Limit Ping"
iptables -t filter -A input_rule -p icmp --icmp-type echo-request -j DROP -m comment --comment "Drop Ping"

To ten limit by również dotyczył sieci lokalnej. A mi zależy jedynie na ograniczeniu od strony wan i dlatego reguła w tym łańcuchu wymaga podania przełącznika -i z nazwą interfejsu. Dlatego potrzebny był sposób, który by dynamicznie tę nazwę dobrał i tak te powyższe reguły mają taką postać:

iptables -t filter -A input_rule -i $ifname -p icmp --icmp-type echo-request -m limit --limit 50/s --limit-burst 100 -j ACCEPT -m comment --comment "Limit Ping"
iptables -t filter -A input_rule -i $ifname -p icmp --icmp-type echo-request -j DROP -m comment --comment "Drop Ping"

W ten sposób nazwa interfejsu WAN już nie ma znaczenia i może się zmieniać, a reguła i tak zostanie dobrana dla właściwego interfejsu

Ja do tej pory jechałem na swoim FW ale mnie interesuje operowanie na tym mechanizmie z OpenWRT, bo w dużej części przypadków to wymagane jest dodanie 1 lub 2 reguł i to wszystko co przeciętny domownik potrzebuje. Nie ma sensu pisać całego skryptu na xxx linijek, który będzie realizował dokładnie to samo co domyślnie robi OpenWRT.

Ja używam debiana na co dzień, także ja iptables mam w miarę dobrze opanowany, bo w końcu mam na swoim kompie sporo ciekawych regułek. big_smile

Ten domyślny FW co jest w OpenWRT ma przecie cały WAN zablokowany. Jedynie co to ping stwarza zagrożenie, choć u mnie już przestał. big_smile

A poza tym, to zamiast recent, zainteresuj się ipset i dynamicznymi listami adresów

Grunt to wiedzieć, co się dzieje i co się robi. big_smile

Ok mam. big_smile

Tylko tam w tym co dałeś to literówka jest:

network_get_phydev 
network_get_physdev

Jak wykryć?

Właśnie rozmontowałem sobie własny skrypt FW i pododawałem regułki do plików /etc/config/firewall oraz /etc/firewall.user . Praktycznie całą podstawę udało mi się przepisać i w końcu w miarę zrozumieć to przetwarzanie reguł w wykonaniu OpenWRT. Są jednak dwa problemy, których za bardzo nie mogę rozwiązać.

Domyślnie w pliku  /etc/config/firewall jest taki blok:

config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

Czyli zezwalanie na ping od strony WAN. Problem w tym, że ta reguła trafia do zone_wan_input . Chodzi o to, że tam trafiają wszystkie pakiety w stanie NEW. Wszystkie pozostałe są łapane przez wcześniejszą ESTABLISHED,RELATED. Tak stan rzeczy w przypadku ping powoduje, że jeśli ktoś z zewnątrz wyśle ping, to zostanie utworzony wpis w tablicy conntrack'a. Tylko ten pierwszy pakiet zostanie złapany przez tę powyższą regułę, a reszta pójdzie na ESTABLISHED,RELATED . W efekcie można z routerem od strony WAN nawiązać dowolną ilość nowych "połączeń" ping i będą tworzone kolejne wpisy w tablicy, a ta ma skończony rozmiar. Jak się zapełni, to nowe połączenia nie będą nawiązywane.

Można by tę regułę ograniczyć do jakieś hosta via 'option src_ip' ale czasem ten ping na WAN się przydaje. Zatem pomyślałem sobie o jakimś mechanizmie limitowania. No i te regułki w OpenWRT obsługują również limit ale limitowanie tej powyższej nic nie da, bo to ograniczy jedynie pakiety w stanie NEW i w ten sposób ilość jednoczesnych żądań ping ciągle może się zwiększać, nawet jak ustawi się tutaj 1/s -- będą się zwiększać w tempie 1/s. big_smile

Można temu zaradzić przez ładowanie reguł do łańcucha 'input_rule', bo on jest przed tym całym ESTABLISHED,RELATED.

No i pytanie jest, jak to zrobić w sposób właściwy? Czy przez ten /etc/config/firewall da radę skierować regułę do tego łańcucha 'input_rule' ? Z tego co czytałem na wiki to chyba raczej nie za bardzo i trzeba to robić przez plik /etc/firewall.user . No i to rozwiązanie też mi może pasować, tylko pytanie jest, jak dynamicznie dobrać interfejs WAN w tym pliku? Póki co to statycznie tam zdefiniowałem eth0. Niemniej jednak, jak się przeniesie konfigurację na inny router i ten interfejs ulegnie zmianie, to wtedy trzeba będzie przepisywać ten plik /etc/firewall.user .