Nejde ping z jednoho zařízení v síti

[jval]

Untitled Diagram.jpg (57.24 KiB) Zobrazeno 4728 x

Zdravím, mám síť viz příloha.
RPi Zero mi nechce komunikovat s Xiaomi.
Pokud dám na RPi Zero ping 192.168.1.10, tak host unreachable.
Pokud dám na RPi Zero ping kamkoliv jinam, tak OK.
Pokud dám na čemkoliv jiném ping 192.168.1.10, tak OK.
Ping z čehokoliv jiného na 192.168.1.4 také bez problémů.
Tak jsem z toho jelen. Nevíte kde by mohl být zakopaný pes?

Děkuju

[Sidi]

Oba přes Wifi? Nemáš tam zapnuté "Client isolation"?

[jval]

Jestli je tím myšleno toto https://ispforum.cz/viewtopic.php?t=20333 tak ne.

[jval]

Teď jsem ještě zkusil pingnout android tablet, který jede také přes wifi a v pohodě.
Nevím jestli to může mít nějakou souvislost, tak ještě doplním, že mám zapnuté 2,4GHz, tak i 5GHz radio.
Čili doma jedou 4 wifi SSID.

jvtik
jvtik_guests
jvtik2.4
jvtik_guests2.4


jvtik a jvtik2.4 jsou v rozsahu 192.168.1.0/24
jvtik_guests a jvtik_guests2.4 jsou v rozsahu 192.168.2.0/24 (ty můžou jen na net)


Obě zařízení která jsou na tom obrázku s připojením přes wifi jedou na jvtik2.4

[mirek.k]

Jestli je tím myšleno toto https://ispforum.cz/viewtopic.php?t=20333 tak ne.

Jen pozor Default Forward je negace Client Isolation - tedy bys ho měl mít zapnuté.
Mirek

[jval]

Mám to takto.

[mrazek609]

Vždyť podle screenu ti to běží na capsmanu. Tedy v konfiguraci capsmanu -- datapath zaškrtni client to client forwarding.
Ve wireless nic nenastavíš, když jede capsman, ten interface je vypnutý.

[jval]

Už to jede, mockrát děkuji za rady.

[jval]

Zdravím, ještě jednou se vrátím k tomuto tématu. Mám doma domoticz ve spojení s Xiaomi Smart Gateway.
V dokumentaci https://www.domoticz.com/wiki/Xiaomi_Gateway_(Aqara)#Troubleshooting píší něco o tom, že je potřeba vypnout IGMP Snooping.
U všech bridgu mám IGMP Snooping vypnuté.
Nevíte, které nastavení by tomu ještě mohlo vadit?
Iptables jsem nastavil dle toho doporučení.

Děkuji za případné odpovědi.

[Radek.Kovacik]

... v konfiguraci capsmanu -- datapath zaškrtni client to client forwarding.

Co tato volba vlastně znamená? Při čtení popisu na wiki stránkách jsem to nepochopil. To bude klient komunikovat s druhým napřímo, tedy bez AP nebo co to udělá?
Další, co bych v souvislosti s nastavením CAPsMANa a CAPů potřeboval objasnit, je rozdíl v chování při local-forwarding a CAPsMAN forwarding.
Samotné nastavení CAPsMANa i CAPů jsem jakž takž zvládl, že to funguje, ale jsou tam určité věci, které bych potřeboval ještě doladit, ale dostatečně nerozumím tomu, co ta určitá volba znamená.

[hapi]

tragédie...

local forwarding - data z wifi jsou u capsmanu defaultně posílaný tunelem na capsman server. Neúčastní se čehokoliv lokálního na ap. Rovnou jdou do tunelu kterej capsman automaticky vytváří a data pak vylezou na capsman serveru v tom iface který se tam virtuálně vytvoří při napojení capsman apčka. Pokud je ta volba zatrhnutá, chová se to jako normální AP a tedy data nejdou do tunelu ale zůstávaji na iface v apčku kde s nimi můžeš nakládat jako u běžný konfigurace třeba typicky hodit do bridge s eth porty a pak jdou data úplně stejně jako u normálního AP např přímo do ethernetů bez tunelu a dalšího zatěžování cpu. Prostě zatrhnou v tvém případě. Pokud by si měl třeba pokrejvat hotel a mít dvě oddělený sítě, dvě ssid, tak nezatrhnutím docílíš toho že na capsman serveru se třeba stejný ssid spojí do jednoho bridge z různých apček umístěních po hotelu s možností vlastního subnetu atd.. tedy oddělení třeba pro veřejnou část a část pro personal. Tím že se to protuneluje se nesmíchaji data a neni třeba dělat vlany a pasovat je na virtální apčka. Udělá to za tebe. Nebo to jde udělat i tak ža caspman server je někde na druhý straně republiky a data z wifiny se posílají k serveru a odtud teprve jdou do netu.

client to client forwarding... ty voe co by to asi mohlo bejt. Že by klasická izolace klientů? jasně že je.

[Radek.Kovacik]

Díky za objasnění. Takže bez zatržení client to client forwarding se ti dva nebudou vidět, tedy budou navzájem odizolovaní? Já jsem to původně pochopil tak, že zatržením vznikne spojení ad-hoc, tedy bez účasti AP.
Co se týká těch VLAN, to je zrovna můj případ. Aktuálně to mám stejně, jak jsem to měl před překlopením na CAPsMANa - tedy co VLAN, to virtuální AP vytvořené CAPsMANem s nastavením patřičného VLAN ID v datapath profilu. Která z těch konfigurací je lepší (případně méně zatěžující procesor nebo samotnou síť) - s VLAN interfacy v každém CAPu a zatrženém local-forwarding nebo s tím tunelem do CAPsMANA?

[hapi]

Jo pokud budou na stejným AP tak se vidět nebudou.

vlany jsou nejspíš lepší. Na mikrotik foru si lidi stěžují na drastický snížení rychlosti když se to nechá v tunelu. Těžko říct v čem je skutečná chyba, někomu to dělá, někomu ne. Vlany nejspíš budou praktičtější resp. nativnější i když v obou případech jde o "zapouzdření" paketu. Ale vlana má standard, tunel capsmanu ne

[Radek.Kovacik]

Jo pokud budou na stejným AP tak se vidět nebudou.

Tahle informace mne docela překvapila. Pokud tedy budou ve stejné VLANě (a tím pádem i subnetu) a na různých AP, tak se budou vidět i při nezatržení uvedené volby? Já jsem tak nějak podvědomě předpokládal, že pokud je více AP řízených centrálně, že se to bude chovat na všech AP stejně, tedy centralizovaně. Co je pak potřeba k dosažení tohoto stavu, zrušit zatržení client to client forwarding na všech AP?

[hapi]

stejně se bude vidět klient z jednoho ap s klientem na druhým ap. Ta volba řeší jenom otáčení provozu mezi klienty v rámci jednoho AP. Pokud by si chtěl aby klienti nemohly i mezi sebou skrz různá ap tak to chce popřemejšlet jak na to.