Zdravím,
na jednom sajtu, kde jsem měl historicky namixované MT a UBNT klienty, se mi podařilo konečně všechno sjednotit na MT. A slavnostně jsem tak přepnul z 802.11 na nv2.
(Skoro) všechno funguje, ale…
Jeden klient vypíná své zařízení, když ho nepoužívá. A když ho zapne, tak se klient zaregistruje do AP, ale nekomunikuje. Když se podívám do registration table, tak ho vidím, když se podívám na stats, není u něj last-ip!!! Od něj neprojde ping směrem do sítě.
Když ale zkusím jeho IP adresu opingnout zvenčí, okamžitě se chytí, začne odpovídat, ve sats se objeví last-ip, klient začne fungovat.
Jen teď nevím, jestli je to jen časová shoda nebo to soiuvisí s přepnutím na nv2. Děje se to u toho jednoho + ještě se to pravděpodobně jednou stalo u druhého klienta. Na jiných sajtech jsem se s tím nesetkal (netvrdím, že to tam není, ale zatím si nikdo nestěžova = nezjistil jsem to). Porovnal jsem konfigurace AP i klentů a nenašel jsem rozdíl (netvrdím, že jsem to nepřehlédl). A nebo se to jinde neprojevilo jen proto, že se někde děje něco specifického.
Jak na AP, tak na tomhle klientovi je ROS 6.44.5, někteří klienti maji ROS starší. Ale tak je to i na jiných sajtech, kde problém není.
Setkal se prosím někdo s podobnýám problémem?
Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Neodpovídající klient
Spatne anstavena maska, defaultni routa? Prihlasit se pres telnet / ssh na klienta a nebo primo u nej do RB a zkontrolovat.
0 x
s necim podobny jsem se setkal. Akorat u nas byl klient v bridge (mode station-bridge) a routovany nekde jinde, takze MK se tvaril nedostupny po IP a bylo potreba na nej pingnout aby se to rozhejbalo. U nas to nebyl problem, ktery by jsme resili protoze routovany byl jinde a komunikace normalne chodila, jenom nebyl dohled nad koncovim MK. Nase zapojeni bylo MK RT wlan AP -> MK bridge pres wlan1 ST-BR a wlan2 AP -> MK Bridge wlan ST-BR a eth1 -> klient RT. Rekl bych ze problem u nas byl ta 433 v ceste. Chyba bude nekde v castem pouzivani bridge na trase, zkus to drive routovat.
0 x
Maska i routa jsou v pořádku - to by dělalo problémy od vždycky. Ale pro jistotu je to teď zkontrolováno.
Ten problém je na topologicky celkem jednoduché síti (odroutovaný subnet). Cesta mezi routerem a tím klientem je: Router <- opt. spoj -> RB750 (vše v bridgi, používán jen jako switch) - RB600 (ano, ono to ještě opravdu dodnes spolehlivě funguje - zde opět všechny porty v bridgi) [mode=ap-bridge] < . . . > klient SXT [mode=station]
Já už začínám mít podezření na to SXT, že se v něm něco sukuje. On totiž neodešle ani packet (ale neřekne proč), dokud to neprošťouchnu zvenčí.
Ten problém je na topologicky celkem jednoduché síti (odroutovaný subnet). Cesta mezi routerem a tím klientem je: Router <- opt. spoj -> RB750 (vše v bridgi, používán jen jako switch) - RB600 (ano, ono to ještě opravdu dodnes spolehlivě funguje - zde opět všechny porty v bridgi) [mode=ap-bridge] < . . . > klient SXT [mode=station]
Já už začínám mít podezření na to SXT, že se v něm něco sukuje. On totiž neodešle ani packet (ale neřekne proč), dokud to neprošťouchnu zvenčí.
0 x
Ano je to vlastnost NV2 už se to tu řešilo někde. Stávalo se nám to taky. Ale s novým firmwarem už ne, proto mě překvapuje že píšeš že na klientovi i na AP máš poslední.
Bios na klientovi jsi taky aktualizoval?
Bios na klientovi jsi taky aktualizoval?
0 x
Myslíš firmware? Ano, na obou je aktuální. Pro jistotu teď zkontrolováno.honzam píše:Bios na klientovi jsi taky aktualizoval?
0 x
jestli ti to dělá jen jeden klient tak to zkus obejít těmito způsoby.
1. Na klientovi nastav watchdog na bránu.
2. Na AP si vytvoř script který bude neustále pingat dotyčného klienta
1. Na klientovi nastav watchdog na bránu.
2. Na AP si vytvoř script který bude neustále pingat dotyčného klienta
0 x
Tohle nemůže fungovat, protože klient nepingne ven.honzam píše:1. Na klientovi nastav watchdog na bránu.
Jako dočasný workaround to takhle teď mám - ale to není dlouhodobě rozumné řešení.2. Na AP si vytvoř script který bude neustále pingat dotyčného klienta
0 x
zburget píše:Tohle nemůže fungovat, protože klient nepingne ven.honzam píše:1. Na klientovi nastav watchdog na bránu.
Právě. Tím že nepingne ven to způsobí restart a napodruhé (napotřetí) většinou naběhne i s komunikací ven.
Souhlasím že to je obcházení problému ale lepší jak nic
0 x
Jo takhle, jasně, rozumím. No, není to moc systémové řešení, ale lepší jak nic. Tedy pokud někdo nezná "správné" řešení tohohle problému…
0 x
zburget píše:Jo takhle, jasně, rozumím. No, není to moc systémové řešení, ale lepší jak nic. Tedy pokud někdo nezná "správné" řešení tohohle problému…
Řešil jsem to přímo se supportem, ale nepovedlo se jim to nasimulovat. Mě taky ne, je to náhodný problém. Pokud to dokážeš nasimulovat tak jim napiš.
Mě osobně vždy pomohl upgrade AP a klienta. Což tobě nepomohlo tak nevím.
Problém je v tom že se v ARP tabulce nevytvoří záznam. Pomůže například mac ping na klienta a v tu chvíli začne komunikovat a záznam v ARP se vytvoří
0 x
Pro pobavení jsem tohle viděl na capsmanu. Cap kde se takhle choval na 802.11 2.4 platební terminál od Komerčky. Řešení jsem nenašel. Stejnej konfig capsman i stejné AP stejnej model terminálu v druhé pobočce a no problém.
0 x