Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez MrCiek4wski
Ok, chyba już wiem czemu nie działają vlany. Patch do ath10k-ct (bed49a5f6824fcd8757fd27f6b2a4f6ea933bf2f) pojawił się w upstream dopiero 24.02.2020, a paczka z opkg jest datowana jeszcze na 2019 rok. W takim przypadku każdy, kto jest na ath79 i ma ath10k nie będzie mieć VLANów (proszę o potwierdzenie).
@Cezary, budujesz może takie rzeczy?
Pytania z poprzedniego postu pozostają aktualne.
Chciałbym uruchomić 8021x na 5G z dynamicznymi vlanami. Albo (skoro na razie i tak będę tylko na jednym AP), coś takiego:
root@OpenWrt:~# uci show wireless.wifinet5
wireless.wifinet5=wifi-iface
wireless.wifinet5.ssid='mordor'
wireless.wifinet5.encryption='psk2+ccmp'
wireless.wifinet5.device='radio1'
wireless.wifinet5.mode='ap'
wireless.wifinet5.wpa_disable_eapol_key_retries='1'
wireless.wifinet5.key='[...]'
wireless.wifinet5.network='gulan'
wireless.wifinet5.isolate='0'
wireless.wifinet5.wpa_psk_file='/etc/config/wireless.pskfile'
wireless.wifinet5.dynamic_vlan='1'
wireless.wifinet5.vlan_tagged_interface='mordorin'
wireless.wifinet5.macaddr='[...]'Drobna modyfikacja handlera hostapd z netifd i działa, bo w ap_config.c z hostapd widać jak parsuje parametry w postaci token=value, a tokeny jakie obsługuje to vlanid i keyid
root@OpenWrt:/etc/config# cat wireless.pskfile
keyid=mgmt vlanid=10 00:00:00:00:00:00 a0a1a2a3
keyid=lan vlanid=15 00:00:00:00:00:00 b0b1b2b3
keyid=radek_priv vlanid=20 00:00:00:00:00:00 c0c1c2c3
keyid=iot_printer vlanid=30 xx:xx:xx:xx:xx:xx d0d1d2d3
#keyid=iot_roomba vlanid=31 yy:yy:yy:yy:yy:yy e0e1e2e3
keyid=iot_roomba_temp vlanid=31 00:00:00:00:00:00 f0f1f2f3Edit:
Jak będzie wyglądać przepustowość na tym radyjku po włączeniu programowego vlan? Z tego co rozumiem, szyfrowanie będzie wykonywał CPU, nie ath10k, bo jest jakiś problem z obsługą tego w hw.
Jak też sprawa się ma w przypadku ath9? Ten już obługuje oddzielne klucze MSK dla vlanów w hw, czy rozwiązanie również jest w sw?
Witam. Sprawa wygląda nstępująco:
root@OpenWrt:~# iw phy; echo
Wiphy phy1
...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* outside context of a BSS
...
Frequencies:
* 2412 MHz [1] (20.0 dBm)
...
Wiphy phy0
...
Supported interface modes:
* IBSS
* managed
* AP
* monitor
* mesh point
* P2P-client
* P2P-GO
* P2P-device
...
Frequencies:
* 5180 MHz [36] (30.0 dBm)
...
root@OpenWrt:~# opkg list-installed *ath*k*; echo
ath10k-firmware-qca988x-ct-htt - 2019-10-03-d622d160-1
kmod-ath10k-ct - 4.14.180+2019-09-09-5e8cd86f-1
kmod-ath9k - 4.14.180+4.19.120-1-1
kmod-ath9k-common - 4.14.180+4.19.120-1-1
root@OpenWrt:~# uname -a; echo
Linux OpenWrt 4.14.180 #0 Sat May 16 18:32:20 2020 mips GNU/Linux
root@OpenWrt:~# cat /etc/device_info /etc/openwrt_*; echo
DEVICE_MANUFACTURER='OpenWrt'
DEVICE_MANUFACTURER_URL='https://openwrt.org/'
DEVICE_PRODUCT='Generic'
DEVICE_REVISION='v0'
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.3'
DISTRIB_REVISION='r11063-85e04e9f46'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 19.07.3 r11063-85e04e9f46'
DISTRIB_TAINTS=''
r11063-85e04e9f46ath9k działa. Gdzieś czytałem, że sterownik do ath10k był już patchowany by zgłaszał opcję wysyłania surowych ramek 802.11, które firmware od candeli rzekomo obsługuje. Powiedzcie proszę czy to tylko w Archer C7 v2 czy ogólnie vlany na wlan w ath10k nie działają? Zaznaczę też, że to nie jest C7 tylko przerobione D7.
@mar_w
1. Dokładnie tak
2. Dokładnie tak
No tak, dziękuję za zauważenie tej kosmicznej gafy... No, trochę wstyd jak na taki błąd. Brama nie jest moja, a providera i ja nie mam do niej żadnego dostępu, ani żadnych personalnych configów dnat czy snat. Jej jedynym zadaniem jest przekazywanie ruchu z mojej publicznej podsieci, więc wbić się mogę tylko na moje publiczne IP. Także zamiast
firewall.@rule[0].src_ip='51.68.136.1'
powinno być:
firewall.@rule[0].src_ip='51.68.x.x'
To by też wyjaśniało powód braku reroutów w kernelu, przecież pakiety wychodzą z moim IP, a nie bramy, więc nie były markowane.
Mam jeszcze tylko jedno pytanie teoretyczne.
Aby takie ustawienie działało (tj. wszystko na bramę tun0 za wyjątkiem markowanych pakietów, które mają iść na bramę eth0) trzeba było ręcznie wypełnić nową tablicę trasowania (u mnie 'mgmt') z routingem dla eth0. W przypadku stałego IP to nie jest problem. Natomiast jak coś takiego skonfigurować, gdy dostajemy adres i bramę dynamicznie (z dhcp)?
Serdecznie wszystkich witam. Posiadam następującą konfigurację na urządzeniu z bezpośrednim dostępem do publicznego IP:
root@OpenWrt:~# for i in network firewall; do uci show $i; echo; done
network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.wan=interface
network.wan.proto='static'
network.wan.force_link='1'
network.wan.ipv6='0'
network.wan.ipaddr='51.68.x.x'
network.wan.netmask='255.255.248.0'
network.wan.gateway='51.68.136.1'
network.wan.dns='1.1.1.1'
network.wan.delegate='0'
network.wan.ifname='eth0'
network.@rule[0]=rule
network.@rule[0].mark='255'
network.@rule[0].lookup='252'
network.@route[0]=route
network.@route[0].gateway='51.68.136.1'
network.@route[0].interface='wan'
network.@route[0].target='0.0.0.0/0'
network.@route[0].table='mgmt'
network.@route[1]=route
network.@route[1].netmask='255.255.248.0'
network.@route[1].target='51.68.136.0'
network.@route[1].interface='wan'
network.@route[1].table='mgmt'
firewall.@defaults[0]=defaults
firewall.@defaults[0].input='DROP'
firewall.@defaults[0].output='DROP'
firewall.@defaults[0].forward='DROP'
firewall.@defaults[0].syn_flood='1'
firewall.@defaults[0].drop_invalid='1'
firewall.@zone[0]=zone
firewall.@zone[0].name='wan'
firewall.@zone[0].mtu_fix='1'
firewall.@zone[0].network='wan'
firewall.@zone[0].forward='DROP'
firewall.@zone[0].input='DROP'
firewall.@zone[0].masq='1'
firewall.@zone[0].family='ipv4'
firewall.@zone[0].output='DROP'
firewall.@include[0]=include
firewall.@include[0].path='/etc/firewall.user'
firewall.@rule[0]=rule
firewall.@rule[0].name='EnableDirectMgmt'
firewall.@rule[0].target='MARK'
firewall.@rule[0].proto='tcp'
firewall.@rule[0].family='ipv4'
firewall.@rule[0].set_mark='255'
firewall.@rule[0].src_port='x'
firewall.@rule[0].dest='*'
firewall.@rule[0].src_ip='51.68.136.1'
firewall.@rule[1]=rule
firewall.@rule[1].src='*'
firewall.@rule[1].family='ipv6'
firewall.@rule[1].target='DROP'
firewall.@rule[1].dest='*'
firewall.@rule[1].proto='all'
firewall.@rule[1].name='BlockIPv6-frwd'
firewall.@rule[2]=rule
firewall.@rule[2].src='*'
firewall.@rule[2].family='ipv6'
firewall.@rule[2].proto='all'
firewall.@rule[2].target='DROP'
firewall.@rule[2].name='BlockIPv6-in'
firewall.@rule[3]=rule
firewall.@rule[3].proto='all'
firewall.@rule[3].dest='*'
firewall.@rule[3].target='DROP'
firewall.@rule[3].family='ipv6'
firewall.@rule[3].name='BlockIPv6-out'
firewall.@rule[4]=rule
firewall.@rule[4].src='wan'
firewall.@rule[4].family='ipv4'
firewall.@rule[4].target='ACCEPT'
firewall.@rule[4].name='AllowMgmt-inwan'
firewall.@rule[4].dest_port='x'
firewall.@rule[4].proto='tcp'
firewall.@rule[5]=rule
firewall.@rule[5].family='ipv4'
firewall.@rule[5].target='ACCEPT'
firewall.@rule[5].dest='wan'
firewall.@rule[5].name='AllowMgmt-outwan'
firewall.@rule[5].mark='255'
firewall.@rule[5].src_port='x'
firewall.@rule[5].proto='tcp'
firewall.@rule[6]=rule
firewall.@rule[6].proto='all'
firewall.@rule[6].name='AllowVPN-outwan'
firewall.@rule[6].dest='wan'
firewall.@rule[6].extra='-m owner --uid-owner openvpn'
firewall.@rule[6].target='ACCEPT'
firewall.@rule[6].family='ipv4'
root@OpenWrt:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
128 prelocal
255 local
254 main
253 default
0 unspec
252 mgmt
#
# local
#
#1 inr.ruhepZałożenie jest takie, by do internetu mogło wyjść tylko openvpn, reszta ma być na eth0 blokowana. Konfiguracja openvpn z kolei jest zrobiona tak, że przy podłączeniu do serwera ten ustawia bramę główną na siebie, więc urządzenie ma dostęp do internetu po podłączeniu (zakładamy tutaj, że output dla tun0 jest dozwolony).
Problem rodzi się gdy muszę administrować urządzeniem zdalnie. Jeżeli otworzę odpowiednie porty, to otrzymuje ono zapytanie, natomiast ze względu na gw odpowiedź jest routowana przez vpn i do mnie nie trafia (tzn. trafia ale z IP VPN i na innym porcie). Dlatego mam oddzielną tablicę dla trafficu trafiającego na port x ssh. Jeżeli zechcę poadministrować, to przez KVM włączam regułę 'EnableDirectMgmt' i mam dostęp ssh.
Niestety, nie działa to jak należy. Po nawiązaniu połączenia ovpn urządzenie na porcie x nie odpowiada. Dopiero gdy dodam ip route add z moim IP i poprzednim gw do main mogę się połączyć, co wskazywałoby na to, że kernel nadal korzysta z tablicy main, a nie mgmt. Tak być nie powinno, bo po mangle output kernel powinien ponownie sprawdzić trasowanie.
Co robię źle?
O ciekawe... i do tego sfp+. Jest na to openwrt? Sprawdziłem w ToH, nie ma modelu, co do supportu Alpine AL21400 w openwrt nie widzę niczego. Rozumiem, że nie ma?
No cóż... w takim razie będę kombinował 
Jakie to mikrotiki mają te 2.5?
Ok, a może istnieją jakieś embedy z portem 10G i do tego zarządzalny switch z portami gigabitowymi i jednym 10G (+ SFP)? Całego kompa nie chce stawiać, bo bym chyba musiał sieć włączać na 3h dziennie żeby przypadkiem nie zgłaszać do Innogy upadłości konsumenckiej...
Witam,
Chciałbym zapytać o radę jake mocne routery (bez wifi) albo routery z jakimi prockami powinienem brać pod uwagę spełniające następujące kryteria:
1. 40+MBps (BAJtów) wydajności na ChaCha20 z openssl (jakieś hw crypto dla aes mile widziane)
2. Zdolność routowania l3 bez offloadu (potrzebne będzie QoS) o prędkości 5Gbps
2.1 Switch mający co najmniej 5 gigabitowych portów i jeden 5G full-duplex albo 10G half-duplex połączony z SoC (tj. 5x1000BASE-T full-d, każdy na oddzielnym vlanie) albo
2.2 5 oddzielnych gigabitowych nic
3. SFP (nie obowiązkowe)
4. PoE out dla wszystkich portów, konfigurowalne (nie obowiązkowe)
5. Obsługa wszystkiego w openwrt
Szukałem w ToH i tagami na stronie openwrt, ale nie wiem jak szukać po przepustowości między switchem a cpu. Zaczynam wątpić czy takie monstrum istnieje na rynku konsumenckim...
Przypatrywałem się EdgeRouter X-SFP, ale na stronie techdata piszą, że nieobsługiwany jest port sfp i crypto, poza tym nie wiem jak z routowaniem (jak połączony jest switch z cpu i czy ten jego mediatek coś takiego by pociągnął?)
Ok, dziękuję za wyjaśnienie. Czyli jednak to co napisałem jest prawdą, bo ten switch ma po prostu niekompletną implementację vlanów, co by oznaczało, że korzystanie z nich na tym switchu nijak ma się do bezpieczeństwa, co gorsza - włączenie tej funkcjonalności tylko bezpieczeństwo obniża (atak jw.). Tak więc, izolacja klientów kablowych w tym Atherosie bądź np. doprowadzanie dwóch sieci wlan przez tagowanie powinno być unikane, chyba że utrata połączenia nie jest problemem.
Ciekawe czy jeszcze jakieś modele low-end od Atheros czy Mediatek mają takie kwiatki...
R.Ł.
Nie może być tak, że ruch tego samego MAC wpada z kilku dziurek na raz. I na tym polega cały problem.
Zgadzam się w 100%. Dokładnie ten fakt jest wykorzystywany w tym ataku, tyle że w przypadku utworzenia vlanów powinny być traktowane jak dwa oddzielne zbiory dziurek. Nie są, stąd problemy, brak możliwości bridgowania i możliwy DoS. Rozważenia poziomu l2 bez vlanów zajęły mi cały paragraf, nie wiem jak mogło Ci to umknąć...
Byłoby to wyjaśnieniem dziwnego wyglądu arl: zastanówmy się co by było, gdyby switch miał wyłączoną obsługę vlan. Gdyby switch dostał 2 takie same pakiety z 2 takimi samymi adresami src na 2 różnych portach, to by zgłupiał: coś takiego w topologii ethernet nie powinno mieć miejsca. Jedynym *sensownym* wytłumaczeniem takiego zjawiska jest przepięcie komputera z jednego portu do drugiego. Z tego powodu, biorąc pod uwagę kolejność występowania naszych przesyłanych pakietów, lądują one w porcie 0 i nie są przekazywane do portów 1 i 2, bo switch uznał, że komputer został przepięty właśnie na port routera, gdy router z kolei po prosu wysyła forwardowany pakiet. Stąd brak komunikacji unicast. Broadcast nie potrzebuje mapowania, więc nie ma go w arl, bo wysyłany jest wszędzie.
Nie masz tablic w układach SOHO, które są przystosowane do takich cudów.
Czy mógłbym prosić o wyjaśnienie, bo nie rozumiem? W sensie nie przystosowane do tworzenia niezależnych tablic dla vlanów? Jeżeli tak, to jakim cudem Archer D7 (i zapewne multum innych urządzeń) właśnie w swconfig zwraca taką tablicę?
Nie rozumiem w jaki sposób jest to cecha gdy z jednego vlanu możesz spowodować zakłócenie działania drugiego vlanu właśnie na poziome l2... Przecież po to są vlany aby na tym poziome delikwentów izolować...
Jeżeli uważasz, że coś takiego nie jest możliwe, to w takim razie napisz swoje zdanie na ten temat, właśnie po to opisałem ten problem dogłębnie aby ktoś z większą wiedzą mógł to potwierdzić albo zaprzeczyć i wyjaśnić co ja zorbiłem źle, że coś takiego się dzieje.
Update:
1. Sprawdziłem na Archerze D7 config, miałem zły, po porawie bridge działa, więc jego switch można wykluczyć.
2. swconfig w 18.06 nie zwraca arl_table, więc komenda z postu wyżej nie będzie działać (będzie pusty ekran), niemniej nie wpływa to na sam switch, który nadal jest podatny. Jeżeli załadujecie 19.07 z initramem, to zadziała.
3. Jeżeli znajdujecie się w br-guest albo br-lan stworzonego z vlanu i wlanu będąc podłączonym przez wlan atak nadal można wykonać ustawiając --dest-mac na bcast. Będzie to jednak dosyć głośne. Proszę jednak o sprawdzenie tego, gdyż mam urwaną antenę.
4. Atak działa tylko na elementy powiązane ze switchem, tj. tylko część kablową. Nie oddziałuje on na klientów wifi ani w br-lan, ani w br-guest.
5. Jeżeli atakujecie gateway, a interfejsy sieci lan i guest mają takie same MAC, to atak zadziała, ale sieć guest też nie będzie miała dostępu do wan.
PoC:
Aby przeprowadzić atak można wgrać sobie taką konfigurację:
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ifname 'eth0.10'
option delegate '0'
config interface 'guest'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option ifname 'eth0.20'
option delegate '0'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '10'
option ports '0t 1 4'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '20'
option ports '0t 2 3'root@OpenWrt:~# cat /etc/config/firewall
config defaults
option syn_flood '1'
option input 'DROP'
option forward 'DROP'
option drop_invalid '1'
option output 'DROP'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
option family 'ipv4'
config zone
option network 'guest'
option input 'ACCEPT'
option forward 'REJECT'
option name 'guest'
option output 'ACCEPT'
option family 'ipv4'
config include
option path '/etc/firewall.user'root@OpenWrt:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option force '1'
config dhcp 'guest'
option interface 'guest'
option start '100'
option limit '150'
option leasetime '12h'
option force '1"
config dhcp 'wan'
option interface 'wan'
option ignore '1'Utworzy nam ona 2 interfejsy: lan na eth0.10 i guest na eth0.20. Następnie należy podłączyć po jednej karcie albo urządzeniu do każdej z nich. Po otrzymaniu IP dla kontroli połączenia trzebaby pingować router 192.168.{1,2}.1 z jednego z komputerów, a na drugim odpalić
nping -e <iface> -HNc0 --source-mac <routerMac> --dest-mac <routerMac> --delay 1ms --arp 0.0.0.0Dopóki nie zabijecie programu urządzenie z odpalonym pingiem przestanie otrzymywać odpowiedzi, a jakikolwiek kontakt z routerem będzie zerwany.
Błąd raczej nie może zostać wykorzystany do niczego poza denerwowaniem innych, niemniej wypadałoby wspomnieć gdzieś na jakimś wiki, żeby nie korzystać z ar9331 do izolacji jakichś serwerów wymagających ciągły uptime w sieci lokalnej, np. dhcp albo właśnie gateway (czego raczej i tak nikt nie będzie robił na routerach z tym SoC), albo aby uważać przy konfiguracji w trybie AP.
Jak komuś się chce, to może to zgłosić, jeżeli nie - cóż, jak mówię, nie jest to w absolutnie żaden sposób bug zasługujący na cokolwiek innego niż krótką wzmiankę.
Przy okazji, @Cezary, czy mógłbyś proszę zmienić tytuł na 'Bug w AR724X/AR933X'?
Pozdrawiam,
R.Ł.
Dawno temu miałem problem z bridgowaniem 2 vlanów: https://eko.one.pl/forum/viewtopic.php?id=19288 . Problemu nie rozwiązałem, ustawiłem nietagowane vlany i podmieniłem po prostu switcha na tp-linka. Niestety, dziś na moim Archerze d7 na Owrt musiałem ustawić coś bardzo podobnego, bridgowanie dwóch vlanowych sieci na tym samym switchu (gościnna i bezpieczna), co dało dokładnie takie same rezultaty jak na WR740: przez bridge przechodzą tylko ramki z dest mac broadcast. Jako, że w tym przypadku nie mogłem sobie pozwolić na zwykły nietagowany vlan (potrzebna mi była funkcjonalność ebtables) postanowiłem trochę problem pokopać i udało mi się dojść do jego źródła: wadliwa implementacja tablic arl w switchach atherosu.
Od początku:
Wyobraźmy sobie bardzo hipotetyczny router z 1 ifejsem sieciowym eth0 i jednym 3-portowym (do dyspozycji mamy 2) switechm switch0 z obsługą 802.11q podłączonym pod eth0. Chcemy, aby porty 1 i 2 działały w ramach L2, proste: nie robimy nic albo ustawiamy jeden globalny vlan. Natomiast teraz trochę komplikujemy: nadal chcemy switch L2, ale pomiędzy portami ma nie przechodzić jakiś dany adres mac. Teraz trzeba ustawić 2 różne vlany i je zbridgować na L2, jednocześnie ustawiając odpowiednią zasadę w ebtables. Też porste, prawda? No, jak się okazuje, nie do końca. Teraz z jakiegoś powodu pomiędzy sieciami nie przechodzi unicast. Ok, zepsuliśmy firewall, czyścimy tablicę z ebtables... nadal nic. Na wszelki wypadek czyścimy iptables... też nic. Czyli nie firewall.
Dla testów ustawiamy następującą sieć:
192.168.1.10 (eth10) <----Port 1 (eth0.10)----> router <----Port 2 (eth0.20)----> (eth20) 192.168.1.20
Dla łatwości uznajemy, że router ten nie bierze udziału w tej sieci, tj. albo kontrolujemy go z innej (wyimaginowanej w tej sytuacji), albo przez uart, na br0 nie ma żadnego adresu (unmanaged). Odpalamy sniffery na interfejsach: eth10, eth0.10, eth0, eth0.20, eth20 i otrzymujemy następujące rezultaty:
1. Przy zapytaniu arp o adres 192.168.1.20 z adresu 192.168.1.10 (zapytanie bcast, odpowiedź ucast):
eth10: zapytanie brak odpowiedzi | x
SWITCH | x(?)
eth0: tagowane zapytanie tagowana odpowiedź v ^
eth0.10: zapytanie odpowiedź | | Droga pakietów
br0 | |
eth0.20: zapytanie odpowiedź v ^
eth0: tagowane zapytanie tagowana odpowiedź | |
SWITCH | |
eth20: zapytanie odpowiedź ->----->-
Foto, gdyby się wszystko rozjechało:
Zauważmy, że pomiędzy eth0, eth0.10 i eth0.20 odpowiedzi są przekazywane prawidłowo, czyli problemów w softwarowym bridgu nie ma. Z resztą, jak zauważył @Cezary, gdyby były, to:
[...]żaden router z openwrt by nie działał gdzie domyślnie robiony jest bridge z lanu i wifi.
Coś jest nie tak pomiędzy wysłaniem tagowanej ramki z eth0 (eth0.20) do eth20. Chyba nietrudno zauważyć, że jedyną rzeczą pomiędzy eth0 a eth20 jest SWITCH.
Dla pewności zprawdzamy config vlanów switcha switch0: swconfig dev switch0 show i przypadkiem zauważamy anomailę w sekcji arl_table:
Port 0: MAC (mac eth0)
Port 0: MAC (mac eth20)
Port 0: MAC (mac eth10)
Na pierwszy rzut oka powinno być:
Port 0: MAC (mac eth0)
Port 2: MAC (mac eth20)
Port 1: MAC (mac eth10)
Po chwili zastanowienia dochodzimy jednak do wniosku, że obecność macu eth20 na porcie 0 jest porządana i logiczna, gdyż router bridgując vlany 10 i 20 (interfejsy eth0.10 i eth0.20) bazując na swojej softwarowej tablicy arl, którą można podpatrzeć w brforward, otrzymawszy pakiet na 10 wysyła go na 20 i odwrotnie, spowrotem do switcha z takimi samymi adresami mac. Switch z kolei, widząc przychodzący tagowany pakiet z adresem eth10/eth20 na porcie 0 (tam, gdzie jest eth0), uznaje, że rzeczywiście jest on na porcie 0 i tak to ma działać, w przeciwnym wypadku switch nie wiedziałby gdzie przekierować odpowiedź. A więc poprawna tablica:
Port 0: MAC (mac eth0)
Port 0: MAC (mac eth20)
Port 0: MAC (mac eth10)
Port 2: MAC (mac eth20)
Port 1: MAC (mac eth10)
Dlaczego więc arl_table tak nie wygląda? Moja teoria była taka, że z jakiegoś powodu arl nawet przy 2 oddzielnych vlanach jest nadal wspólny dla całego switcha, tj. nie ma oddzielnego arl dla vlanu 10 i 20. Byłoby to wyjaśnieniem dziwnego wyglądu arl: zastanówmy się co by było, gdyby switch miał wyłączoną obsługę vlan. Gdyby switch dostał 2 takie same pakiety z 2 takimi samymi adresami src na 2 różnych portach, to by zgłupiał: coś takiego w topologii ethernet nie powinno mieć miejsca. Jedynym *sensownym* wytłumaczeniem takiego zjawiska jest przepięcie komputera z jednego portu do drugiego. Z tego powodu, biorąc pod uwagę kolejność występowania naszych przesyłanych pakietów, lądują one w porcie 0 i nie są przekazywane do portów 1 i 2, bo switch uznał, że komputer został przepięty właśnie na port routera, gdy router z kolei po prosu wysyła forwardowany pakiet. Stąd brak komunikacji unicast. Broadcast nie potrzebuje mapowania, więc nie ma go w arl, bo wysyłany jest wszędzie.
Przy braku izolacji tablicy arl rodzi się więc zagrożenie. Co jeżeli (jak ja) mamy na takim niedopracowanym switchu sieć gościnną i własną? Po krótkim namyśle uznałem, że zgodnie z działaniem takiego switcha można spróbować przeprowadzić atak DoS z sieci gościnnej na własną i odwrotnie, aby sprawdzić, czy problemem jest właśnie to, o czym już tak bardzo się rozpisałem. Kluczem w takim wypadku jest tak częstę spamowanie switcha, aby co najmniej jeden pakiet z zespoofowanym adresem src ofiary od atakującego (nas) docierał do switcha POMIĘDZY wysłaniem przez switch pakietu od ofiary adresowanego gdzieś a otrzymaniem odpowiedzi przez switch z kądś adresowanego do ofiary (w przypadku naszego bridga wygląda to tak, że switch JUŻ UZNAŁ za port wychodzący port 0 ZANIM pakiet o zapytanie w ogóle dotarł do dest, więc gdy odpowiedź przychodzi, zgodnie z tablicą arp wyszłaby z tego samego portu, co jest głupie i podejrzewam, że logika switcha po prostu ten pakiet ignoruje, bo nie widzimy żadnych nietagowanych ramek w snifferze na eth0). Wtedy odpowiedź z sieci własnej na vlanie 10 powędruje na port sieci gościnnej o vlanie 20, gdzie zostanie odrzucona. Więc do dzieła!
Atakujący w kablowej sieci gościnnej obrał sobie za ofiarę bramę główną sieci własnej. Wtedy żaden klient w sieci własnej nie będzie mieć dostępu do WAN, bo odpowiedzi bramy głównej będą dropowane na poziome L2 w switchu. Zakładając, że zna adres mac tej bramy, a zna, bo jest jej adminem 
, odpala to, jako atakujący, na PC wpiętym do sieci gościnnej:
nping -e eth0 -HNc0 --source-mac ad:re:so:fi:ar:y0 --dest-mac ad:re:so:fi:ar:y0 --delay 1ms --arp 0.0.0.0(destmac można ustawić jakikolwiek, ja ustawiłem taki sam, żeby nie robić szumu w sieci.)
i, już jako admin, to na niedopracowanym switchu:
while : ; do sleep 1; clear; swconfig dev switch0 show | grep MAC; doneaby zobaczyć czy switch zgłupieje zgodnie z przewidywaniami (dany mac raz będzie na porcie atakującego, bo spamuje, a raz na porcie ofiary, która czasem wysyła jakieś inne pakiety). Jeżeli pakiet zwrotny trafi do switcha w czasie, gdy mac jest na porcie atakującego, mamy upragniony DoS.
Patrzymy na konsolkę i switch zdurniał, bo widać naprzemiennie:
Port 0: MAC (mac eth0)
Port 0: MAC (mac eth20)
i
Port 0: MAC (mac eth0)
Port 2: MAC (mac eth20)
a internetu w mojej sieci nie ma, chociażże tcpdump na bramie głównej mówi co innego
Piszę ten post z prośbą do forumowiczów, by sprawdzili to u siebie. Chyba najłatwiej będzie zbridgować 2 rózne vlany i na utworzonym bridgu postawić serwer dhcp. Niezależnie od lokacji, komunikacja klientów i routera (serwera dhcp) będzie działać ok, bo nie jest przekazywana do 2 portu, natomiast nie będą mogli wysyłać pakietów między sobą, chyba że na bcast. Jeżeli okaże się, że na waszym switchu też występuje ten problem, to napiszcie w poście model takiego switcha. Bo jeżeli nie ma problemu u nikogo, to nie zdurniał switch a ja.
Nie chcę dłużej szkodzić innym i zabierać cenny czas, tak więc dzięki za wytrwałość!
R.Ł.
Ok, chyba widzę:
ctstate RELATED,ESTABLISHEDwyrzuciłem i teraz działa jak trzeba. Czemu fw3 dodaje to automatycznie i jak to wyłączyć?
Mam taką bardzo prostą konfigurację, która nie działa:
root@OpenWrt:~# uci show firewall
firewall.@defaults[0]=defaults
firewall.@defaults[0].input='DROP'
firewall.@defaults[0].output='DROP'
firewall.@defaults[0].forward='DROP'
firewall.@defaults[0].syn_flood='1'
firewall.@defaults[0].drop_invalid='1'
firewall.@zone[0]=zone
firewall.@zone[0].name='lan'
firewall.@zone[0].input='ACCEPT'
firewall.@zone[0].output='ACCEPT'
firewall.@zone[0].network='lan'
firewall.@zone[0].forward='DROP'
firewall.@zone[1]=zone
firewall.@zone[1].name='wan'
firewall.@zone[1].output='ACCEPT'
firewall.@zone[1].input='ACCEPT'
firewall.@zone[1].network='wan'
firewall.@zone[1].forward='DROP'
firewall.@include[0]=include
firewall.@include[0].path='/etc/firewall.user'
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].dest='wan'
firewall.@forwarding[0].src='lan'root@OpenWrt:~# uci show network.wan && uci show network.lan
network.wan=interface
network.wan.proto='static'
network.wan.netmask='255.255.255.0'
network.wan.delegate='0'
network.wan.ipaddr='192.168.2.1'
network.wan.ifname='eth1.10'
network.lan=interface
network.lan.type='bridge'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.delegate='0'
network.lan.ifname='eth1.1'root@OpenWrt:~# for i in FORWARD zone_lan_forward zone_wan_forward; do iptables -L $i; echo; done
Chain FORWARD (policy DROP)
target prot opt source destination
forwarding_rule all -- anywhere anywhere /* !fw3: Custom forwarding rule chain */
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* !fw3 */
DROP all -- anywhere anywhere ctstate INVALID /* !fw3 */
zone_lan_forward all -- anywhere anywhere /* !fw3 */
zone_wan_forward all -- anywhere anywhere /* !fw3 */
Chain zone_lan_forward (1 references)
target prot opt source destination
forwarding_lan_rule all -- anywhere anywhere /* !fw3: Custom lan forwarding rule chain */
zone_wan_dest_ACCEPT all -- anywhere anywhere /* !fw3: Zone lan to wan forwarding policy */
ACCEPT all -- anywhere anywhere ctstate DNAT /* !fw3: Accept port forwards */
zone_lan_dest_DROP all -- anywhere anywhere /* !fw3 */
Chain zone_wan_forward (1 references)
target prot opt source destination
forwarding_wan_rule all -- anywhere anywhere /* !fw3: Custom wan forwarding rule chain */
ACCEPT all -- anywhere anywhere ctstate DNAT /* !fw3: Accept port forwards */
zone_wan_dest_DROP all -- anywhere anywhere /* !fw3 */Chcę, aby gdy coś z 192.168.1.0/24 łączy się z 192.168.2.0/24 pakiety przechodziły, ale pakiety odpowiedzi (tj. z 192.168.2.0/24 do 192.168.1.0/24) już nie. Gdy wykonuję ping ICMP z 192.168.1.214, to otrzymuje on odpowiedź od 192.168.2.133. Co mam źle?
A rzeczywiście, mam ht20 w configu, niedopatrzenie... W każdym razie i tak dziękuję za pomoc.
No, chyba nie tylko luci, ale za rozwianie wątpliwości dziękuję
root@OpenWrt:/# iwinfo wlan1 info
wlan1 ESSID: "OpenWrt2G"
Access Point: XX:XX:XX:XX:XX:XX
Mode: Master Channel: 11 (2.462 GHz)
Tx-Power: 25 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy1
Co do szerokości pasm, to ustawień nie zmieniałem, bo właśnie takie jak napisałeś domyślnie są.
Za noscan dziękuję, pomogło, chociaż i tak nie za bardzo wiem co to robi, nawet po zerknięciu do dokumentacji uci.
Dzięki za naprowadzenie. Niestety, nawet zapisanie mac w tym adresie nic nie dało. Poszukałem w moim backupe stringów binarnych w postaci mojego mac i znalazłem w 0xfdf100, co by się zgadzało z tym commitem, który znalazłem później: https://git.openwrt.org/?p=openwrt/open … 967d7#l102
romfs zaczyna się na offsecie 0xfd0000. Dopiero po zapisaniu w 0x1fc0 i 0xfdf100 oraz oznaczeniu romfs w u-boocie
mtdparts=ath-nor0:128k(u-boot),1152k(kernel),14192k(rootfs),128k(romfs),64k(radio)interfejsy wstają.
Teraz zostaje kwestia tego generic 802.11 i prędkości. AR9550 ma być tak oznaczone? Czy znowu ze sterownikiem coś nie tak?
Offload w openwrt jest domyślnie, czy trzeba samemu pobierać jakieś moduły do kernela? I czy to normalne, że prędkość wifi spada w porównaniu ze stockiem (w moim przypadku 2x)?
Ok, dla pewności wgrałem moje art z backupu:
AP135> set serverip 192.168.100.10
AP135> set ipaddr 192.168.100.1
AP135> tftp 0x81000000 art.bin
dup 1 speed 1000
Using eth0 device
TFTP from server 192.168.100.10; our IP address is 192.168.100.1
Filename 'art.bin'.
Load address: 0x81000000
Loading: #############
done
Bytes transferred = 65536 (10000 hex)
AP135> erase 0x9fff0000 0x9fffffff
Erasing flash...
First 0xff last 0xff sector size 0x10000 255
Erased 1 sectors
AP135> cp.b 0x81000000 0x9fff0000 10000
Copy to Flash... write addr: 9fff0000
done
AP135> printenv
bootargs=[...]mtdparts=ath-nor0:128k(u-boot),1152k(kernel),15040k(rootfs),64k(radio)
...Nadal źle są wykrywane parametry:
root@OpenWrt:/# iwinfo
...
wlan1 ESSID: "OpenWrt"
Access Point: 00:02:03:04:05:06
Mode: Master Channel: 11 (2.462 GHz)
Tx-Power: 25 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy1Gdzie dokładnie jeszcze miały znajdować się te adresy we flash? Mam zmodowaną tablicę w u-boot, wywaliłem partycje w stylu rom, romfs, reserved, bo są one potrzebne tylko do stockowego firmware (przynajmniej tak twierdzi internet). To tam mają być te adresy? Bo jak tak, to przywrócę.
Udało mi się uruchomić tego Archera z openwrt z C7 na stockowym u-boocie po małej modyfikacji. Wifi niestety poprawnie nie działa:
root@OpenWrt:~# logread
...
Sat May 16 18:43:11 2020 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Sat May 16 18:43:11 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sat May 16 18:43:11 2020 daemon.err hostapd: Using interface wlan1 with hwaddr 00:02:03:04:05:06 and ssid "OpenWrt"
Sat May 16 18:43:11 2020 kern.info kernel: [ 30.599907] br-lan: port 2(wlan1) entered disabled state
Sat May 16 18:43:11 2020 daemon.err hostapd: nl80211 driver initialization failed.
Sat May 16 18:43:11 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Sat May 16 18:43:11 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Sat May 16 18:43:11 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sat May 16 18:43:11 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Sat May 16 18:43:12 2020 kern.info kernel: [ 30.655281] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Sat May 16 18:43:12 2020 kern.info kernel: [ 30.661994] br-lan: port 2(wlan1) entered blocking state
Sat May 16 18:43:12 2020 kern.info kernel: [ 30.667448] br-lan: port 2(wlan1) entered forwarding state
Sat May 16 18:43:12 2020 daemon.notice netifd: radio0 (1405): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Sat May 16 18:43:12 2020 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->ENABLED
Sat May 16 18:43:12 2020 daemon.notice netifd: radio0 (1405): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Sat May 16 18:43:12 2020 daemon.notice hostapd: wlan1: AP-ENABLED
Sat May 16 18:43:12 2020 daemon.notice netifd: radio0 (1405): Command failed: Invalid argument
Sat May 16 18:43:12 2020 daemon.notice netifd: radio0 (1405): Device setup failed: HOSTAPD_START_FAILED
Sat May 16 18:43:12 2020 daemon.notice netifd: Network device 'wlan1' link is up
...
Sat May 16 18:44:05 2020 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Sat May 16 18:44:05 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sat May 16 18:44:05 2020 daemon.err hostapd: nl80211 driver initialization failed.
Sat May 16 18:44:05 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Sat May 16 18:44:05 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Sat May 16 18:44:05 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sat May 16 18:44:05 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Sat May 16 18:44:05 2020 daemon.notice netifd: radio0 (1898): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Sat May 16 18:44:05 2020 daemon.notice netifd: radio0 (1898): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Sat May 16 18:44:06 2020 daemon.notice netifd: radio0 (1898): Command failed: Invalid argument
Sat May 16 18:44:06 2020 daemon.notice netifd: radio0 (1898): Device setup failed: HOSTAPD_START_FAILED
...root@OpenWrt:~# iwinfo
wlan1 ESSID: "OpenWrt"
Access Point: 00:02:03:04:05:06
Mode: Master Channel: 11 (2.462 GHz)
Tx-Power: 25 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy1root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.channel='36'
wireless.radio0.hwmode='11a'
wireless.radio0.path='pci0000:00/0000:00:00.0'
wireless.radio0.htmode='VHT80'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.encryption='none'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.channel='11'
wireless.radio1.hwmode='11g'
wireless.radio1.path='platform/ahb/18100000.wmac'
wireless.radio1.htmode='HT20'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'5G nie inicjuje się wogóle, a 2.4 ma coś nie tak z bssid i na dodatek "Hardware: unknown [Generic MAC80211]", ale przynajmniej startuje. Mam wrażenie, że coś jest nie tak ze znalezieniem tych adresów MAC, bo jeżeli ręcznie przypiszę bssid do 5G, to nagle startuje:
root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.channel='36'
wireless.radio0.hwmode='11a'
wireless.radio0.path='pci0000:00/0000:00:00.0'
wireless.radio0.htmode='VHT80'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.encryption='none'
wireless.default_radio0.macaddr='00:01:02:03:04:05'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.channel='11'
wireless.radio1.hwmode='11g'
wireless.radio1.path='platform/ahb/18100000.wmac'
wireless.radio1.htmode='HT20'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'root@OpenWrt:~# iwinfo
wlan0 ESSID: "OpenWrt"
Access Point: 00:01:02:03:04:05
Mode: Master Channel: 36 (5.180 GHz)
Tx-Power: 23 dBm Link Quality: unknown/70
Signal: unknown Noise: -103 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
wlan1 ESSID: "OpenWrt"
Access Point: 00:02:03:04:05:06
Mode: Master Channel: 11 (2.462 GHz)
Tx-Power: 25 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy1root@OpenWrt:~# logread
...
Sat May 16 22:26:56 2020 daemon.err hostapd: Configuration file: /var/run/hostapd-phy1.conf
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.001234] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.172966] br-lan: port 2(wlan1) entered blocking state
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.178483] br-lan: port 2(wlan1) entered disabled state
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.184151] device wlan1 entered promiscuous mode
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.189084] br-lan: port 2(wlan1) entered blocking state
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.194509] br-lan: port 2(wlan1) entered forwarding state
Sat May 16 22:26:56 2020 daemon.err hostapd: Using interface wlan1 with hwaddr 00:02:03:04:05:06 and ssid "OpenWrt"
Sat May 16 22:26:56 2020 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Sat May 16 22:26:56 2020 kern.info kernel: [ 31.504764] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Sat May 16 22:26:58 2020 kern.warn kernel: [ 32.968749] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
Sat May 16 22:26:58 2020 kern.info kernel: [ 32.985520] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410'
Sat May 16 22:26:58 2020 kern.info kernel: [ 32.991834] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0'
Sat May 16 22:26:58 2020 kern.info kernel: [ 32.999994] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 20904 iram: 26056'
Sat May 16 22:26:58 2020 kern.warn kernel: [ 33.062839] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.077613] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat May 16 22:26:58 2020 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->ENABLED
Sat May 16 22:26:58 2020 daemon.notice hostapd: wlan1: AP-ENABLED
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.120201] br-lan: port 3(wlan0) entered blocking state
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.125638] br-lan: port 3(wlan0) entered disabled state
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.131281] device wlan0 entered promiscuous mode
Sat May 16 22:26:58 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->HT_SCAN
Sat May 16 22:26:58 2020 daemon.notice netifd: Network device 'wlan1' link is up
Sat May 16 22:26:58 2020 daemon.notice hostapd: Switch own primary and secondary channel to get secondary channel with no Beacons from other BSSes
Sat May 16 22:26:58 2020 daemon.err hostapd: Using interface wlan0 with hwaddr 00:01:02:03:04:05 and ssid "OpenWrt"
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.271105] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.277815] br-lan: port 3(wlan0) entered blocking state
Sat May 16 22:26:58 2020 kern.info kernel: [ 33.283203] br-lan: port 3(wlan0) entered forwarding state
Sat May 16 22:26:58 2020 daemon.notice hostapd: wlan0: interface state HT_SCAN->ENABLED
Sat May 16 22:26:58 2020 daemon.notice hostapd: wlan0: AP-ENABLED
Sat May 16 22:26:58 2020 daemon.notice netifd: Network device 'wlan0' link is up
...Skąd OpenWrt odczytuje adresy dla interfejsów wlan i czemu nie widzi, że phy1 to AR9550? Dla 2.4G adres też jest zły. Może coś uszkodziłem podczas wgrywania i tego nie wiem. ART jest cały, sprawdziłem.
Poza tym, na działających już wlanach sprawdziłem przepustowość i wyszło, że jest gorzej niż na stockowym firmware (~2x wolniej i dla phy0 i phy1). Czy można to jakoś poprawić (zastosować jakiś offload, zmiana firmware z ct na inne, itd...)?
Dobra, wstaje Porobiłem parę testów i widzę jedną anomailę: 192.168.1.100 - kabel, 192.168.1.101 - wifi
Sam ping:
PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=281 ms
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=96.7 ms
64 bytes from 192.168.1.101: icmp_seq=3 ttl=64 time=118 ms
64 bytes from 192.168.1.101: icmp_seq=4 ttl=64 time=137 ms
64 bytes from 192.168.1.101: icmp_seq=5 ttl=64 time=168 ms
64 bytes from 192.168.1.101: icmp_seq=6 ttl=64 time=187 ms
64 bytes from 192.168.1.101: icmp_seq=7 ttl=64 time=211 ms
64 bytes from 192.168.1.101: icmp_seq=8 ttl=64 time=231 ms
64 bytes from 192.168.1.101: icmp_seq=9 ttl=64 time=50.4 ms
64 bytes from 192.168.1.101: icmp_seq=10 ttl=64 time=75.7 ms
64 bytes from 192.168.1.101: icmp_seq=11 ttl=64 time=93.4 ms
64 bytes from 192.168.1.101: icmp_seq=12 ttl=64 time=117 ms
64 bytes from 192.168.1.101: icmp_seq=13 ttl=64 time=142 ms
64 bytes from 192.168.1.101: icmp_seq=14 ttl=64 time=165 ms
64 bytes from 192.168.1.101: icmp_seq=15 ttl=64 time=189 ms
64 bytes from 192.168.1.101: icmp_seq=16 ttl=64 time=202 ms
64 bytes from 192.168.1.101: icmp_seq=17 ttl=64 time=233 ms
64 bytes from 192.168.1.101: icmp_seq=18 ttl=64 time=48.0 ms
64 bytes from 192.168.1.101: icmp_seq=19 ttl=64 time=73.6 ms
64 bytes from 192.168.1.101: icmp_seq=20 ttl=64 time=95.7 ms
64 bytes from 192.168.1.101: icmp_seq=21 ttl=64 time=2.55 ms
64 bytes from 192.168.1.101: icmp_seq=22 ttl=64 time=2.88 ms
64 bytes from 192.168.1.101: icmp_seq=23 ttl=64 time=161 ms
64 bytes from 192.168.1.101: icmp_seq=24 ttl=64 time=183 ms
64 bytes from 192.168.1.101: icmp_seq=25 ttl=64 time=204 ms
64 bytes from 192.168.1.101: icmp_seq=26 ttl=64 time=26.3 ms
64 bytes from 192.168.1.101: icmp_seq=27 ttl=64 time=31.5 ms
64 bytes from 192.168.1.101: icmp_seq=28 ttl=64 time=53.5 ms
64 bytes from 192.168.1.101: icmp_seq=29 ttl=64 time=480 ms
64 bytes from 192.168.1.101: icmp_seq=30 ttl=64 time=510 ms
64 bytes from 192.168.1.101: icmp_seq=31 ttl=64 time=533 ms
64 bytes from 192.168.1.101: icmp_seq=32 ttl=64 time=163 ms
64 bytes from 192.168.1.101: icmp_seq=33 ttl=64 time=186 ms
64 bytes from 192.168.1.101: icmp_seq=34 ttl=64 time=210 ms
64 bytes from 192.168.1.101: icmp_seq=35 ttl=64 time=232 ms
64 bytes from 192.168.1.101: icmp_seq=36 ttl=64 time=46.8 ms
64 bytes from 192.168.1.101: icmp_seq=37 ttl=64 time=74.0 ms
64 bytes from 192.168.1.101: icmp_seq=38 ttl=64 time=96.5 ms
^C
--- 192.168.1.101 ping statistics ---
39 packets transmitted, 38 received, 2.5641% packet loss, time 89ms
rtt min/avg/max/mdev = 2.552/160.813/533.054/123.708 msiperf + ping:
Connecting to host 192.168.1.101, port 5201
[ 5] local 192.168.1.100 port 47008 connected to 192.168.1.101 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 29.2 MBytes 245 Mbits/sec 2 255 KBytes
[ 5] 1.00-2.00 sec 27.0 MBytes 227 Mbits/sec 2 182 KBytes
[ 5] 2.00-3.00 sec 27.4 MBytes 230 Mbits/sec 2 205 KBytes
[ 5] 3.00-4.00 sec 32.5 MBytes 273 Mbits/sec 1 253 KBytes
[ 5] 4.00-5.00 sec 41.0 MBytes 344 Mbits/sec 0 345 KBytes
[ 5] 5.00-6.00 sec 46.3 MBytes 388 Mbits/sec 1 329 KBytes
[ 5] 6.00-7.00 sec 53.8 MBytes 451 Mbits/sec 0 430 KBytes
[ 5] 7.00-8.00 sec 59.2 MBytes 497 Mbits/sec 0 520 KBytes
[ 5] 8.00-9.00 sec 61.0 MBytes 512 Mbits/sec 0 600 KBytes
[ 5] 9.00-10.00 sec 48.6 MBytes 408 Mbits/sec 0 653 KBytes
[ 5] 10.00-11.00 sec 43.8 MBytes 367 Mbits/sec 0 700 KBytes
[ 5] 11.00-12.00 sec 48.8 MBytes 409 Mbits/sec 0 744 KBytes
[ 5] 12.00-13.00 sec 62.5 MBytes 524 Mbits/sec 0 805 KBytes
[ 5] 13.00-14.00 sec 58.8 MBytes 493 Mbits/sec 0 857 KBytes
[ 5] 14.00-15.00 sec 61.2 MBytes 514 Mbits/sec 17 660 KBytes
[ 5] 15.00-16.00 sec 61.2 MBytes 514 Mbits/sec 0 740 KBytes
[ 5] 16.00-17.00 sec 63.8 MBytes 535 Mbits/sec 0 799 KBytes
[ 5] 17.00-18.00 sec 63.8 MBytes 535 Mbits/sec 0 841 KBytes
[ 5] 18.00-19.00 sec 65.0 MBytes 545 Mbits/sec 0 881 KBytes
[ 5] 19.00-20.00 sec 65.0 MBytes 545 Mbits/sec 0 935 KBytes
[ 5] 20.00-21.00 sec 66.2 MBytes 556 Mbits/sec 0 986 KBytes
[ 5] 21.00-22.00 sec 66.2 MBytes 556 Mbits/sec 0 1.00 MBytes
[ 5] 22.00-23.00 sec 67.5 MBytes 566 Mbits/sec 0 1.00 MBytes
[ 5] 23.00-24.00 sec 66.2 MBytes 556 Mbits/sec 0 1.00 MBytes
[ 5] 24.00-25.00 sec 67.5 MBytes 566 Mbits/sec 0 1.00 MBytes
[ 5] 25.00-26.00 sec 63.8 MBytes 535 Mbits/sec 28 757 KBytes
[ 5] 26.00-27.00 sec 61.2 MBytes 514 Mbits/sec 12 597 KBytes
[ 5] 27.00-28.00 sec 61.2 MBytes 514 Mbits/sec 0 667 KBytes
[ 5] 28.00-29.00 sec 61.2 MBytes 514 Mbits/sec 0 732 KBytes
[ 5] 29.00-30.00 sec 60.0 MBytes 503 Mbits/sec 0 790 KBytes
[ 5] 30.00-31.00 sec 60.0 MBytes 503 Mbits/sec 17 609 KBytes
[ 5] 31.00-32.00 sec 62.5 MBytes 524 Mbits/sec 0 686 KBytes
[ 5] 32.00-33.00 sec 61.2 MBytes 514 Mbits/sec 0 742 KBytes
[ 5] 33.00-34.00 sec 63.8 MBytes 535 Mbits/sec 0 795 KBytes
[ 5] 34.00-35.00 sec 63.8 MBytes 535 Mbits/sec 0 854 KBytes
[ 5] 35.00-36.00 sec 65.0 MBytes 545 Mbits/sec 0 909 KBytes
[ 5] 36.00-37.00 sec 65.0 MBytes 545 Mbits/sec 0 959 KBytes
[ 5] 37.00-38.00 sec 63.8 MBytes 535 Mbits/sec 0 1007 KBytes
[ 5] 38.00-39.00 sec 67.5 MBytes 566 Mbits/sec 0 1.00 MBytes
[ 5] 39.00-40.00 sec 67.5 MBytes 566 Mbits/sec 0 1.00 MBytes
[ 5] 40.00-41.00 sec 66.2 MBytes 556 Mbits/sec 0 1.00 MBytes
[ 5] 41.00-42.00 sec 65.0 MBytes 545 Mbits/sec 20 754 KBytes
[ 5] 42.00-43.00 sec 60.0 MBytes 503 Mbits/sec 10 592 KBytes
[ 5] 43.00-44.00 sec 61.2 MBytes 514 Mbits/sec 0 666 KBytes
[ 5] 44.00-45.00 sec 62.5 MBytes 524 Mbits/sec 0 732 KBytes
[ 5] 45.00-46.00 sec 65.0 MBytes 545 Mbits/sec 0 793 KBytes
[ 5] 46.00-47.00 sec 65.0 MBytes 545 Mbits/sec 0 853 KBytes
^C[ 5] 47.00-47.55 sec 35.0 MBytes 537 Mbits/sec 0 882 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-47.55 sec 2.72 GBytes 491 Mbits/sec 112 sender
[ 5] 0.00-47.55 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminatedPING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=430 ms
64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=8.63 ms
64 bytes from 192.168.1.101: icmp_seq=3 ttl=64 time=5.01 ms
64 bytes from 192.168.1.101: icmp_seq=4 ttl=64 time=4.49 ms
64 bytes from 192.168.1.101: icmp_seq=5 ttl=64 time=4.37 ms
64 bytes from 192.168.1.101: icmp_seq=6 ttl=64 time=4.42 ms
64 bytes from 192.168.1.101: icmp_seq=7 ttl=64 time=5.10 ms
64 bytes from 192.168.1.101: icmp_seq=8 ttl=64 time=6.18 ms
64 bytes from 192.168.1.101: icmp_seq=9 ttl=64 time=4.73 ms
64 bytes from 192.168.1.101: icmp_seq=10 ttl=64 time=7.20 ms
64 bytes from 192.168.1.101: icmp_seq=11 ttl=64 time=7.23 ms
64 bytes from 192.168.1.101: icmp_seq=12 ttl=64 time=11.6 ms
64 bytes from 192.168.1.101: icmp_seq=13 ttl=64 time=28.9 ms
64 bytes from 192.168.1.101: icmp_seq=14 ttl=64 time=1.95 ms
64 bytes from 192.168.1.101: icmp_seq=15 ttl=64 time=33.2 ms
64 bytes from 192.168.1.101: icmp_seq=16 ttl=64 time=7.18 ms
64 bytes from 192.168.1.101: icmp_seq=17 ttl=64 time=4.55 ms
64 bytes from 192.168.1.101: icmp_seq=18 ttl=64 time=5.10 ms
64 bytes from 192.168.1.101: icmp_seq=19 ttl=64 time=2.51 ms
64 bytes from 192.168.1.101: icmp_seq=20 ttl=64 time=11.3 ms
64 bytes from 192.168.1.101: icmp_seq=21 ttl=64 time=11.6 ms
64 bytes from 192.168.1.101: icmp_seq=22 ttl=64 time=11.9 ms
64 bytes from 192.168.1.101: icmp_seq=23 ttl=64 time=6.76 ms
64 bytes from 192.168.1.101: icmp_seq=24 ttl=64 time=6.34 ms
64 bytes from 192.168.1.101: icmp_seq=25 ttl=64 time=4.34 ms
64 bytes from 192.168.1.101: icmp_seq=26 ttl=64 time=5.99 ms
64 bytes from 192.168.1.101: icmp_seq=27 ttl=64 time=2.56 ms
64 bytes from 192.168.1.101: icmp_seq=28 ttl=64 time=4.31 ms
64 bytes from 192.168.1.101: icmp_seq=29 ttl=64 time=0.884 ms
64 bytes from 192.168.1.101: icmp_seq=30 ttl=64 time=8.77 ms
64 bytes from 192.168.1.101: icmp_seq=31 ttl=64 time=9.68 ms
64 bytes from 192.168.1.101: icmp_seq=32 ttl=64 time=9.48 ms
64 bytes from 192.168.1.101: icmp_seq=33 ttl=64 time=5.31 ms
64 bytes from 192.168.1.101: icmp_seq=34 ttl=64 time=3.64 ms
64 bytes from 192.168.1.101: icmp_seq=35 ttl=64 time=6.93 ms
64 bytes from 192.168.1.101: icmp_seq=36 ttl=64 time=7.76 ms
64 bytes from 192.168.1.101: icmp_seq=37 ttl=64 time=4.04 ms
64 bytes from 192.168.1.101: icmp_seq=38 ttl=64 time=4.26 ms
64 bytes from 192.168.1.101: icmp_seq=39 ttl=64 time=9.21 ms
64 bytes from 192.168.1.101: icmp_seq=40 ttl=64 time=8.90 ms
64 bytes from 192.168.1.101: icmp_seq=41 ttl=64 time=8.37 ms
64 bytes from 192.168.1.101: icmp_seq=42 ttl=64 time=1.33 ms
64 bytes from 192.168.1.101: icmp_seq=43 ttl=64 time=6.59 ms
64 bytes from 192.168.1.101: icmp_seq=44 ttl=64 time=6.35 ms
64 bytes from 192.168.1.101: icmp_seq=45 ttl=64 time=7.61 ms
64 bytes from 192.168.1.101: icmp_seq=46 ttl=64 time=10.4 ms
64 bytes from 192.168.1.101: icmp_seq=47 ttl=64 time=7.45 ms
64 bytes from 192.168.1.101: icmp_seq=48 ttl=64 time=5.12 ms
64 bytes from 192.168.1.101: icmp_seq=49 ttl=64 time=5.10 ms
^C
--- 192.168.1.101 ping statistics ---
49 packets transmitted, 49 received, 0% packet loss, time 96ms
rtt min/avg/max/mdev = 0.884/16.006/429.538/59.947 msArcher D7 jest reklamowany na 1,3Gbps, 192.168.1.101 to Snapdragon 835 oddalony od Archera ~0cm, jego max prędkość to ~800Mbps, 192.168.1.100 to Realtek 1Gbps. Czy w takim przypadku prędkości nie powinny oscylować ~700-750Mbps? Poza tym, ktoś z właścicieli Archera D7 może się wypowiedzieć na temat tych pingów? Obawiam się, że niektóre z tych kondensatorów były związane z anteną...
Poza tematem, w związku z tym, że to pudełeczko leżało sobie długo na strychu i popadło w zapomnienie, spróbuję z niego zrobić Archera C7, jako że bebechy to w praktyce archer c7 v2,v3. Pamieć 8Mb i RAM 64Mb od modemu Broadcoma wylutuję i wstawię do innego routera z 4/32. Nie powinno to chyba wpłynąć na działanie Archera D7? Również, czy ktoś może wytłumaczyć to?
https://openwrt.org/toh/tp-link/archer- … #boot_logs
...
[ 0.896826] m25p80 spi0.0: found s25fl128s, expected m25p80
[ 0.902532] m25p80 spi0.0: s25fl128s (16384 Kbytes)
[ 0.908358] 5 tp-link partitions found on MTD device spi0.0
[ 0.914014] Creating 5 MTD partitions on "spi0.0":
[ 0.918902] 0x000000000000-0x000000020000 : "u-boot"
[ 0.925413] 0x000000020000-0x00000016df58 : "kernel"
[ 0.932084] 0x00000016df58-0x000000ff0000 : "rootfs"
[ 0.938410] mtd: device 2 (rootfs) set to be root filesystem
[ 0.944211] 1 squashfs-split partitions found on MTD device rootfs
[ 0.950509] 0x000000400000-0x000000ff0000 : "rootfs_data"
[ 0.957672] 0x000000ff0000-0x000001000000 : "art"
[ 0.964122] 0x000000020000-0x000000ff0000 : "firamware"
...ArcherC7v2_en_eu_3_15_3_up_boot(180305).bin
mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),8256k(mib0),64k(ART)Dziękuję bardzo za te cenne informacje! Czy mogę jeszcze poprosić o C894 i C895? Nie jestem pewien, czy też wyrwałem czy ich nie było. Tym razem trochę dalej bo okolice karty wifi.
Witam wszystkich,
jak w temacie, urwałem (nie pytajcie jak, błagam, bo będę zmuszony zawstydzić się po raz kolejny...) 1 kondensator (C180) i 2 oporniki (R274, R271) mniej więcej w okolicach AR8327N, na dolnej warstwie płyty. Zmierzyłby ktoś proszę parametry tych urawnych części? Albo może ktoś podzieli się schematem (chociaż wątpie, aby ktoś miał)?
Mam też pytanie do rezystorów pullup i pulldown dla tx i rx: czemu linia tx routera ma jednocześnie rezystor i pullup i pulldown, a rx nie ma żadnego? Czy aby przypadkiem oba nie powinny być pullup, skoro domyślnie uart jest w stanie high?
RŁ
TL-WR740N Ver. 4.26. Wydawało mi się, że wszystkie 740 mają eth0 i eth1(?), ale akurat na tym coś jest nie tak z PHY i muszę korzystać z vlanów.
PS: Właśnie, czy to PHY? Problem z eth1 jest taki, że nawet kiedy do niego nie podłączony jest kabel, to czasami carrier jest widoczny jako 1 (jest połączony). Skoro za identyfikację stanu linii odpowiedzialny jest PHY i gdyby coś za PHY było uszkodzone, to albo byłby problem z inicjacją i błędy w dmesg od sterownika albo carrier byłby cały czas 0, to czy napewno uszkodzone jest PHY? Wychodziłem z założenia, że jeżeli tak jest, to nie może to mieć wpływu na eth0. Czy to jest prawda, czy się mylę?
Próbowałem chyba wszystkiego, od zmiany metryki po randomizowanie MACów, setageing i czyszczenie tablic z brforward, ustawienia domyślne... nie działa nic, nie pojmuję co w tak prostym ustawieniu może się popsuć. Wyczyszciłem ovrelay, zrobiłem co napisałeś, ale dodałem vlan o id 2. Inaczej jak ma router wiedzieć który vlan jest który, kiedy w lan definiuję mu eth0.X?
config:
network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.lan=interface
network.lan.type='bridge'
network.lan.ifname='eth0.1 eth0.2'
network.lan.proto='static'
network.lan.netmask='255.255.255.0'
network.lan.ipaddr='192.168.1.1'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].ports='0t 2 3 4'
network.@switch_vlan[0].vid='1'
network.@switch_vlan[1]=switch_vlan
network.@switch_vlan[1].device='switch0'
network.@switch_vlan[1].vlan='2'
network.@switch_vlan[1].vid='2'
network.@switch_vlan[1].ports='0t 1'eko.one.pl → Posty przez MrCiek4wski
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc