1

(9 odpowiedzi, napisanych Oprogramowanie)

Z wiersza poleceń wydaj taką komendę:
net use * /delete /y

2

(10 odpowiedzi, napisanych Oprogramowanie)

SORRY , nie sprawdziłem na openwrt
Iptables w openwrt nie obsługuje modułu string

Co do samej zasady działania to nie istnieje w tym przypadku problem nadmiernego obciążenia opisywany przez Cezarego.
A to dlatego, ze nie blokujemy adresów IP a słowo kluczowe w zapytaniu DNS
Z blokowaniem youtube według sposobu Cezarego byłby problem, ponieważ na tych samych adresach IP co youtube pracują też inne googlowe usługi.
Dlatego sposób z wykorzystaniem modułu string jest optymalny.
Niestety przynajmniej na razie niedostępny w openwrt

3

(10 odpowiedzi, napisanych Oprogramowanie)

Jeżeli chodzi o mój sposób, to możesz tak również zablokować youtube.
Reszta googlowych gadżetów będzie działała

4

(10 odpowiedzi, napisanych Oprogramowanie)

A ja użyłem takiej reguły:

dla całego zakresu sieci wewnętrznej:
/sbin/iptables -A FORWARD -s 192.168.1.0/24 -m string --string "facebook" --algo bm --to 65535 -j DROP

lub dla wybranego zakresu sieci wewnętrznej:
/sbin/iptables -A FORWARD -m iprange --src-range 192.168.1.40-192.168.1.125 -m string --string "facebook" --algo bm --to 65535 -j DROP

Nie trzeba wymuszać DNS-ów routera
Działa dla http i https

5

(10 odpowiedzi, napisanych Oprogramowanie)

Nie zmieniałem, świeżutka instalacja i od razu precz wink

6

(10 odpowiedzi, napisanych Oprogramowanie)

Mam /etc/config/openvpn_recipes

Jeszcze jedna ciekawostka tak OT
Odinstalowałem transmission i obsługę drukarki a pliki transmission i p910nd w /etc/config pozostały hmm

7

(10 odpowiedzi, napisanych Oprogramowanie)

Dzięki.
Błąd zgłoszony.
Ręczną konfigurację potrafię zrobić, ale ciekawy byłem czy w Luci CC jest równie fajna sekcja do konfiguracji VPN-a jak w Gargoyle.

8

(10 odpowiedzi, napisanych Oprogramowanie)

Zainstalowałem pakiet luci-app-openvpn w wersji git-15.179.51004-cf2e3f6-1
W menu Luci mam nową sekcję, ale po wybraniu pojawia się poniższy komunikat.
Nie znalazłem opisu dotyczącego instalacji OpenVPN-a w wersji CC
Może tutaj kilka słów da się napisać dla "not advanced user's" ?

/usr/lib/lua/luci/dispatcher.lua:360: Failed to execute cbi dispatcher target for entry '/admin/services/openvpn'.
The called action terminated with an exception:
/usr/lib/lua/luci/cbi.lua:241: Unable to read UCI data: openvpn
stack traceback:
    [C]: in function 'assert'
    /usr/lib/lua/luci/dispatcher.lua:360: in function 'dispatch'
    /usr/lib/lua/luci/dispatcher.lua:135: in function </usr/lib/lua/luci/dispatcher.lua:134>

9

(11 odpowiedzi, napisanych Oprogramowanie)

replay111 napisał/a:

Tak, dokladnie chodzi o Ubee EVW3226 ;-)

Nie mogłem się doprosić o cisco wiec zostałem z tym szajsem.

Ja mam Cisco i też było źle po przejściu na BB
Problem jest w czasie odnawiania dzierżawy adresu IP

10

(11 odpowiedzi, napisanych Oprogramowanie)

Znany problem.
Rozwiązanie:
opkg remove luci-app-mwan3
opkg remove mwan3
reboot

Odpowiedź masz w tym temacie:
http://eko.one.pl/forum/viewtopic.php?id=11192

OK, doczytałem:
"usunięcie z obrazów luci dla lantiq pakietów mwan3/luci-app-mwan3"

Czy według Ciebie nie jest zasadne usunięcie tych pakietów z pozostałych dystrybucji?

Cezary, widzę, że w swojej dystrybucji BB usunąłeś mwan3/luci-app-mwan3 dnia 2015-04-02
Jednak dystrybucja LuCi tych zmian nie zawiera, co więcej ostatnie wydanie jest z 2015-03-28
Myślałem, że LuCi to twoje BB z GUI a tymczasem okazuje się że nie?

Ja problem rozwiązałem instalując BB z ze strony openwrt.
Oznacza to, że w obrazach Cezarego jest coś nie tak, chociaż nie udało się ustalić co.
Swoją walkę prowadziłem w tym temacie:
http://eko.one.pl/forum/viewtopic.php?id=10997

Jasne, mój błąd.
Nawet usunąłem posta jak się zorientowałem
Ale zdążyliście go przeczytać i odpowiedzieć :-)

16

(54 odpowiedzi, napisanych Oprogramowanie)

Posadziłem wersję z tej lokalizacji:
https://downloads.openwrt.org/barrier_b … x/generic/

Problemy ustąpiły.

Jutro doinstaluję vpn-a, stworzę konfigurację identyczną z tą która sprawiała problemy i przedstawię ostateczne wnioski.

Gumis84 w tym temacie staramy się rozwikłać zagadkę dotyczącą BB
Dla problemów z Gargoyle twórz nowy temat lub przeszukaj już istniejące.

17

(54 odpowiedzi, napisanych Oprogramowanie)

Może takich kwiatków jest więcej.
Szukam więc dalej.
Cały czas liczę też na pomoc, jeżeli ktokolwiek ma jakiś nowy pomysł

18

(54 odpowiedzi, napisanych Oprogramowanie)

Problem jak widać znany:
https://dev.openwrt.org/ticket/16754#no1

Niestety u mnie nie rozwiązało to problemu, ale może komuś pomoże.

19

(54 odpowiedzi, napisanych Oprogramowanie)

Różnic brak
Hmmmmmm.....

A może ma to jakiś związek z ipv6 ??

Szukam różnic pomiędzy Gargoyle a BB i zaczynam chyba już brzytwy się chwytac

20

(54 odpowiedzi, napisanych Oprogramowanie)

Oprócz liczby pakietów i bajtów różnic brak

21

(54 odpowiedzi, napisanych Oprogramowanie)

Nie za bardzo zrozumiałem, co mam sprawdzić
Podpowiesz ?

22

(54 odpowiedzi, napisanych Oprogramowanie)

Sytuacja wygląda następująco.
- Swój adres wan pinguje
- jakiś adres z tej samej klasy pinguje
- bramę pinguję
- 8.8.8.8 nie pinguję

Więc raczej nie jest to problem z przydziałem adresu na wanie.
Po za tym problem rozwiązuje restart firewalla, co też wyklucza nieprawidłowy przydział na wanie.

root@OpenWrt:~# ping 89.69.174.96
PING 89.69.174.96 (89.69.174.96): 56 data bytes
64 bytes from 89.69.174.96: seq=0 ttl=63 time=55.153 ms
64 bytes from 89.69.174.96: seq=1 ttl=63 time=19.114 ms
^C
--- 89.69.174.96 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 19.114/37.133/55.153 ms
root@OpenWrt:~# ping 89.69.174.93
PING 89.69.174.93 (89.69.174.93): 56 data bytes
64 bytes from 89.69.174.93: seq=0 ttl=64 time=0.337 ms
64 bytes from 89.69.174.93: seq=1 ttl=64 time=0.264 ms
^C
--- 89.69.174.93 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.264/0.300/0.337 ms
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89.69.172.1     0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~# ping 89.69.172.1
PING 89.69.172.1 (89.69.172.1): 56 data bytes
64 bytes from 89.69.172.1: seq=0 ttl=255 time=10.397 ms
64 bytes from 89.69.172.1: seq=1 ttl=255 time=16.289 ms
64 bytes from 89.69.172.1: seq=2 ttl=255 time=7.752 ms
^C
--- 89.69.172.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.752/11.479/16.289 ms
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89.69.172.1     0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

23

(54 odpowiedzi, napisanych Oprogramowanie)

Odkryłem, że mogę wywołać efekt braku internetu ręcznie

Wystarczy, że wywołam komendę:
ifup wan

Więc w razie pytań i pomysłów mogę sprawdzać na bieżąco

24

(54 odpowiedzi, napisanych Oprogramowanie)

Pingi wyglądają następująco:

root@OpenWrt:~# ping google.com
ping: bad address 'google.com'

root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable

root@OpenWrt:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.346 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.293 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.293/0.319/0.346 ms
root@OpenWrt:~#

Więc nie jest to problem dns-ów

Jedna różnica jaką widzę to tablica routingu.

Tak wygląda jak net działa:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89-69-172-1.dyn 0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

A tak jak nie działa:

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         89.69.172.1     0.0.0.0         UG    0      0        0 eth0.2
89.69.172.0     *               255.255.252.0   U     0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

Widać, że format zapisu bramy jest różny.

Kolejny pad za 24 godziny, więc podpowiadajcie co jeszcze sprawdzić.

25

(54 odpowiedzi, napisanych Oprogramowanie)

Zainstalowany vpn to openvpn-polarssl
Ale w czasie badań nie jest uruchomiony.

Wan to UPC, sprzęt Cisco EPC3212