Przejdź do treści forum
eko.one.pl
OpenWrt, Linux, USB, notebooki i inne ciekawe rzeczy
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Opcje wyszukiwania (Strona 2 z 11)
Tak się zastanawiam dlaczego Netgear zrobił to w ten sposób:
factory: partition@2e00000 {
label = "factory";
reg = <0x2e00000 0x100000>;
read-only;
};
Przecież bardziej logiczne będzie umieszczenie factory na końcu pamięci. Tak jak to zasugerował Cezary.
I tak mnie natchnęło kilka linijek niżej:
&pcie {
status = "okay";
pcie0 {
mt76@0,0 {
reg = <0x0000 0 0 0 0>;
device_type = "pci";
mediatek,mtd-eeprom = <&factory 0x8000>;
ieee80211-freq-limit = <5000000 6000000>;
};
};
pcie1 {
mt76@1,0 {
reg = <0x0000 0 0 0 0>;
device_type = "pci";
mediatek,mtd-eeprom = <&factory 0x0000>;
ieee80211-freq-limit = <2400000 2500000>;
};
};
};
Nie wiem jak to działa, ale czy ten ROM to kod dla procesora w routerze, czy radyjka mają własne procesory i to jest właśnie program dla nich? Bo jeśli to drugie to być może zmiana fizycznej lokalizacji spowoduje, że radyjka nie będą działać.
Jeżeli masz problem z DNS to przetestuj czy działa nslookup
# nslookup google.pl 8.8.8.8
Jeżeli zadziała to sprawdź jako drugi parametr IP twojego DNS
Jeśli nie działa to znaczy, że coś blokuje
nesus napisał/a:Podłaczę się pod temat, gdyż nie chciałbym nowego nabytku od razu uwalić.
Który plik wrzucić na pena:
...-initramfs-kernel.bin
...-squashfs-kernel.bin ???
Czym one się różnią?
Hmm, a przeczytałeś ten wątek od początku? https://eko.one.pl/forum/viewtopic.php? … 99#p218799
Skoro to tap0 jest włączony do bridge to blokowanie na tym interface powinno być realizowane na poziomie warstwy łącza danych. Bo bridge jest urządzeniem warstwy łącza danych. Twoje reguły dotyczą warstwy sieciowej i transportowej, które są powyżej łącza danych. Jeżeli bridge jest prawidłowo zaimplementowany to każda ramka, która pojawi się na tap0 musi być przekazana do br-lan bez analizowania co zawierają pakiety wewnątrz ramki.
W moim przypadku ta.key wygląda następująco:
-----BEGIN OpenVPN Static key V1-----
9d3481ce280eb1855556ec61485bbbe9
[ciach]
2aa076f7f26db27d94ab574410804846
-----END OpenVPN Static key V1-----
batorencjusz napisał/a:idzie to jakoś ogarnąć czy bez sprzętowej separacji na switchu temat nie do przeskoczenia?
Obawiam się, że nie zrozumiałeś co to jest VLAN.
VLAN zapewnia separację na poziomie ramki ethernetowej. Jeśli dwa komputery są w tym samym VLAN to mogą do siebie przesyłać ramki ethernetowe. I nie ma tu znaczenia adres IP tylko adres MAC i numer VLAN. To co nazywasz sprzętową separacją na switchu to jest właśnie VLAN. 
Uważam, że te reguły są zbędne. Dokładniej: nie mają szansy zadziałać.
A jeśli działają to znaczy, że ja czegoś nie rozumiem.
Dodaj:
key-direction 1
<tls-auth>
tu wstaw klucz ta.key
</tls-auth>
krzysztof.keska napisał/a:Tue Mar 26 11:11:45 2019 daemon.err openvpn(wolimex)[13100]: TCP: connect to [AF_INET]79.187.162.62:1194 failed: Connection refused
Tue Mar 26 11:11:51 2019 daemon.err openvpn(wolimex)[13100]: TCP: connect to [AF_INET]79.187.162.62:1194 failed: Connection refused
Tue Mar 26 11:12:15 2019 daemon.err openvpn(wolimex)[13246]: TCP: connect to [AF_INET]79.187.162.62:1194 failed: Connection refused
Tue Mar 26 11:12:21 2019 daemon.err openvpn(wolimex)[13246]: TCP: connect to [AF_INET]79.187.162.62:1194 failed: Connection refused
Tue Mar 26 11:13:18 2019 daemon.err openvpn(wolimex)[13325]: event_wait : Interrupted system call (code=4)
Tue Mar 26 11:14:21 2019 daemon.err openvpn(wolimex)[13700]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 11:14:21 2019 daemon.err openvpn(wolimex)[13700]: TLS Error: TLS handshake failed
Jak na mój gust to nie masz zdefiniowanego w konfigu:
tls_auth /etc/openvpn/ta.key 1
Rozumiem co chciałeś zrobić. Twoje reguły są czytelne. Zastanawiam się czy potrzebne.
Chciałem zrozumieć jak to działa.
rufik napisał/a:ebtables -I FORWARD -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I FORWARD -o tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I INPUT -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I OUTPUT -o tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
Ciekawe podejście. Protokół IP to warstwa 3 w modelu ISO/OSI. Bridge to warstwa 2.
Proszę pokaż wynik polecenia:
Cezary napisał/a:Później w /etc/config/wireless zmieniasz option network lan na option network guest.
I w zaproponowanej przeze mnie konfiguracji DNS zastąp wlan słowem guest.
Tak mi coś po głowie chodzi by zrobić dwie sekcje dnsmasq w /etc/config/dhcp:
# uci add_list dhcp.@dnsmasq[0].notinterface='wlan'
# uci add_list dhcp.@dnsmasq[1].interface='wlan'
Reszta wg. uznania
Hmm, a co to za urządzenie 192.168.100.1?
Może nie obsługuje zapytań z innej sieci niż 192.168.100.0/24.
Sprawdź czy działa:
# nslookup miejsce1.home - 192.168.100.1
tinware napisał/a:Jak mogę dodać w DNSMASQ, aby domenę *.home przeszukiwał mi na serwerze po VPN, zamiast po DNSach modemów, czyli od operatorów.
Wypróbuj
uci add_list dhcp.@dnsmasq[0].server='/home/<IP servera DNS po VPN>'
Ten wpis możesz powtarzać tyle razy ile domen chcesz zdefiniować
tinware napisał/a:config interface 'vpn'
option ifname 'tun0'
option _orig_ifname 'tun0'
option _orig_bridge 'false'
option proto 'dhcp'
option dns '192.168.100.1'
Co to za VPN?
Jeśli stosujesz DHCP, to powinieneś otrzymać konfigurację DNS dla tego połączenia.
Sprawdź
# cat /tmp/resolv.conf.auto
Jest to o tyle praktyczne, że system sam dba o to by dodawać i usuwać wpisy w trakcie podnoszenia/zamykania interface'ów
Mam most zrobiony na R6220. Mój konfig sieci:
config interface 'wlan'
option proto 'static'
option netmask '255.255.255.0'
option dns '192.168.1.250'
option gateway '192.168.1.250'
option ipaddr '192.168.1.249'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option dns '192.168.1.1'
option gateway '192.168.1.250'
option ipaddr '192.168.2.1'
onfig interface 'bridge'
option proto 'relay'
option network 'lan wlan'
Resztę pominąłem.
Jeśli chcesz połączyć się z relayem od strony LAN to musisz użyć adresu 192.168.2.1.
W tym celu musisz ustawić na komputerze adres z sieci 192.168.2.0/24
Królik napisał/a:Tak. 99 z allegro.
Moje są z tego samego źródła
Nie skojarzyłem, że to jest "problem z trzema rodzajami partycji".
Myślę, ze warto zaryzykować, bo nie wszystkie R6220 mają z tym problem.
vip napisał/a:Niestety ten pierwszy ma problem z trzema rodzajami partycji
Co masz na myśli?
Kupiłem dwa używane R6220 i właśnie połączyłem je mostem radiowym na 5GHz. Działa.
Nie ma sprawy. Poproszę tylko namiary na instrukcję jak to zrobić.
Dla potomnych. Jeśli ktoś ma podobny problem.
Należy wyedytować plik /etc/init.d/relayd.
Szukamy procedury "start_relay()". Procedura ta kończy się poleceniem "procd_close_instance (linia 96).
Tuż powyżej wstawiamy poniższy kod:
[ciach]
local routers router # empty
config_get routers "$cfg" router
for router in $routers; do
procd_append_param command -R "$router"
done
[ciach]
Teraz z pliku /etc/config/network w sekcji "bridge" dodajemy opcję router:
# uci add_list network.bridge.router='192.168.1.3:172.16.15.0/24'
teraz nasz config powinien wyglądać podobnie do poniższego wpisu:
[ciach]
config interface 'bridge'
option proto 'relay'
option network 'lan wwan'
list router '192.168.1.3:172.16.15.0/24'
[ciach]
Teraz wystarczy zrestartować relayd
# /etc/init.d/relayd restart
I możemy się cieszyć obsługą statycznego routingu na pseudobrige'u
Dzięki Cezary.
Już tam zajrzałem, ale miałem nadzieję, że coś przeoczyłem.
Cześć,
Mam problem z konfiguracją relayd. Potrzebuję dodać statyczny routing przy użyciu opcji -R, ale nigdzie nie znalazłem wskazówki jak mógłbym to zrobić z wykorzystaniem konfiguracji w /etc/config/network.
Moja obecna konfiguracja
config interface 'bridge'
option proto 'relay'
option network 'lan wlan'
W wyniku relayd uruchamia się z następująco:
# /usr/sbin/relayd -I br-lan -I wlan1 -B -D
a potrzebuję:
# /usr/sbin/relayd -I br-lan -I wlan1 -B -D -R 192.168.1.3:172.16.15.0/24
Jakieś pomysły?
mgrlukasz napisał/a:root@R6220:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.1.2 0.0.0.0 UG 0 0 0 wg0
0.0.0.0 95.155.112.1 0.0.0.0 UG 0 0 0 eth0.2
95.155.112.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0.2
172.16.1.0 0.0.0.0 255.255.255.192 U 10 0 0 wg0
192.168.0.0 172.16.1.2 255.255.255.0 UG 10 0 0 wg0
192.168.2.0 0.0.0.0 255.255.255.128 U 0 0 0 br-lan
Masz dwie trasy domyślne. Router wysyła ruch domyślny przez pierwszy gateway na liście czyli 172.16.1.2.
Deamon VPN szykuje paczkę do wysłania i posyła przez sieć. Czyli znów przez default gateway.
Brakuje ci trasy do serwera VPN. Czyli coś w stylu:
route add -host <IP serwera VPN> gateway 95.155.112.1 dev eth0.2
route del default dev eth0.2
Znalezione posty: 26 do 50 z 275