Természetesen december 23-án frissítettem a router-emet devel snapshotból készített saját image-dzsel, viszont ezúttal nem tudott beboot-olni. Szóval itt vagyok az ünnepek alatt router nélkül.
Mivel nem szeretném kidobni, recovery módban tftp szerverről szeretném boot-olni. Mielőtt feleslegesen kísérleteznék, a tftp szerver elérhetőségét tesztelem. A desktop gépemnek van két hálózati interface-e, az egyiken közvetlenül neten van a gép a kábelmodemen keresztül, a másik interface-nek adtam egy 192.168.1.66/24-es címet statikusan. Erre az interface-re dugtam rá a picike notebook-omat, amelynek szintén statikus címet adtam: 192.168.1.86/24, default route 192.168.1.66.
A desktop gépemen elindítottam a tftp szervert. A szerver működik, mert loopback interface-en kiszolgál:
tftp 127.0.0.1
tftp> get wr842nv3_tp_recovery.bin
tftp> quit
ls wr842nv3_tp_recovery.bin
wr842nv3_tp_recovery.bin
Nem nulla hosszal van ott a file, tényleg kiszolgált a szerver. Ugyanakkor a kis notebook-ról:
tftp 192.168.1.66
tftp> get wr842nv3_tp_recovery.bin
Transfer timed out.
tftp> quit
A szerver oldalon a logban:
in.tftpd[29812]: tftpd: read(ack): No route to hostNéztem Wiresharkkal szerver oldalon:
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.1.86 192.168.1.66 TFTP 78 Read Request, File: wr842nv3_tp_recovery.bin, Transfer type: netascii
2 0.029644 192.168.1.66 192.168.1.86 TFTP 558 Data Packet, Block: 1
3 0.029961 192.168.1.86 192.168.1.66 ICMP 586 Destination unreachable (Communication administratively filtered)
4 5.000286 192.168.1.86 192.168.1.66 TFTP 78 Read Request, File: wr842nv3_tp_recovery.bin, Transfer type: netascii
5 5.003284 192.168.1.66 192.168.1.86 TFTP 558 Data Packet, Block: 1
6 5.003499 192.168.1.86 192.168.1.66 ICMP 586 Destination unreachable (Communication administratively filtered)Tűzfalon a tftpd-t kinyitottam, s megnéztem, a 69-es udp portot tudja a tűzfal a szolgáltatáshoz tartozónak.
Ebben a kontextusban mit jelent a Destination unreachable (Communication administratively filtered) üzenet, miért rúgja le a kapcsolatot a szerver kliens gép, de gondolom, azon belül a tűzfalam? Mi az, ami a tftp-ben speciális, másként kellene csinálni?
Jobban megnézve a Wireshark logot, a kliens dobja el a szerver válasz csomagját. De miért?
Megoldás: Nyers erővel kinyitottam az 1024-65535 udp portokat kliensen is, szerveren is, már a 69-esen túl.
- 417 megtekintés
Hozzászólások
Mert nem ismered a TFTP protokollt.
A transfer request is always initiated targeting port 69, but the data transfer ports are chosen independently by the sender and receiver during the transfer initialization. The ports are chosen at random according to the parameters of the networking stack.
Vagy engedélyezd IP-t bármely porttal vagy használd a tftp conntrack modult!
- A hozzászóláshoz be kell jelentkezni
Éreztem, hogy van ebben valami turpisság. Szóval választ magának egy bármilyen portot.
használd a tftp conntrack modult
A szerver oldalra kell?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
A tuzfalhoz kell, tehat mindenhova, ahol tuzfalazol.
- A hozzászóláshoz be kell jelentkezni
Annyiban fura, hogy mindkét gépen be van töltve az nf_conntrack_tftp modul. Mindegy, azt hiszem, erre az interface-re kinyitok minden 1024-65535 közti UDP portot. Ez most úgyis pont-pont kapcslat, ideiglenes, csak erre.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Elméletben újabb kernelek esetén nem elég globálisan belőni, hanem megfelelő szabályok kellenek.
Kipróbáltam legújabb Alpine-on és nekem sem működött a tftp ct helper:
1. egyrészt a neten fellelhető példák 99%-a és az nftables dokumentáció (!) is hibásnak tűnik, ugyanis hibát dob a tűzfal a szabályok betöltésekor
2. ct helper után a "set" nélkül, csak a megfelelő helper nevét megadva elfogadja már a szintaxist (ezt egy helyen találtam egy levelezőlistán), de olyan mintha nem lenne hatása
Több időt most nem akartam rászánni, de ez tűzfal bugnak tűnik, amit jó lenne megvizsgálni. Első körben debuggolni kellene, hogy a helper hook egyáltalán működik-e. Az sem ártana, ha az nftables conntrack helper dokumentációját valaki frissítené és kibővítené..
- A hozzászóláshoz be kell jelentkezni
Mindenesetre köszönöm a segítséget, mert az első hozzászólásodból tudtam meg, hogy lényegében bármelyik porton mehet a kommunikáció, ezt az elején beszéli meg a kliens és a szerver. Ez kellett ahhoz, hogy meg tudjam javítani a routeremet.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Így, hogy mindkét oldalon kinyitottam 1024-65535 tartományban minden UDP portot, működik. Már csak a NetworkManager manageléséből kell kivenni az interface-t, mert, ha elveszti a carriert, akkor csinál egy ifdown-t.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Amikor már azt hiszem, végre minden jó, kiderül, hogy már a két gép közti ping sem megy. :( Közben a másik interface-emen még van net.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mondjuk, ha az interface-t 162.168.1.66/24-re konfigurálom 192.168.1.66/24 helyett, akkor nem csoda, hogy nem működik...
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Sztem húzd ki netet, ha nagyon óvatos akarsz leni, lődd le teljesen a tűzfalat és úgy próbálkozz! PXE boot-ot akarsz ha jól értem, és ahhoz még egy dhcp szervert is be kell majd állítanod. Nem hiányzik az a tűzfal :)
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
- A hozzászóláshoz be kell jelentkezni
Ennél minimálisan szofisztikáltabb megoldást szeretnék. Nem szép, de az még belefér, hogy a notebook - teszt -, majd későbbiekben router felé néző interface felé, felől minden udp forgalmat engedjek, mert az befelé néz, onnan nincs veszély, az lehet laza szabályozású. A net felé néző interface-en meg szigor van, mert az közvetlenül, publikus IP-vel van a neten.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Meg aztán különben is látszott az ARP kérésből, hogy 192.168.0.86 a router, míg a tftp szerverről azt vélelmezi, hogy 192.168.0.66 a címe. Nosza, legyen. Csak TP-Link gyári firmware-t engedett így letölteni, egyből OpenWrt-t nem, de sose legyen nagyobb baj. Kijött a tégla üzemmódból, a gyári firmware fut rajta, elérem már a 192.168.0.1 címen a webszerverét. Nyertem. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ez egy szép nap:
ssh router
BusyBox v1.31.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r15225-bfc433efd4
-----------------------------------------------------tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ügyi vagy! De most már ne piszkáld! :-D
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
- A hozzászóláshoz be kell jelentkezni
Vakmerő voltam. Lett devel snapshotból újabb build ma. Éreztem, hogy kijavították a bugot. Upgrade-eltem, mondván, ha nem jön be, már megvan az út, hogyan tudom meggyógyítani. Viszont valóban kijavították.
ssh router
BusyBox v1.31.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r15354-1508841b4e
-----------------------------------------------------
[0 locsemege@router ~]$ uname -r
5.4.85
A promptot meghamisítottam, nyilván nem az itteni nicknevem a user. A kernelverzió viszont valódi! :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni