Dotaz: Protokol pro discovery a konfiguraci zařízení na ethernetovém segmentu

[OldFrog {Ondra Nemecek}]

Mějme ethernetovou síť s neznámou TCP/IPv4 adresací a v ní více zařízení - průmyslové desky s custom embedded systémem. A chtějme k ethernetu připojit svůj pc a prostřednictvím něho všechna zařízení najít a nakonfigurovat, zejména jejich TCP/IPv4 parametry - ip adresu, bránu a možná pár dalších hodnot. Jaký byste volili protokol?

Ten embedded systém má omezené možnosti, TCP/IP stack je implementovaný ve firmware. Hardware je již hotový (takže konfigurace přes sériový port, usb, bluetooth nebo wifi nepřipadá v úvahu), firmware se dá upravit. Laické zadání zní „aby to bylo jako Winbox na MikroTiku“.

Nynější implementace spočívá v UDP broadcastu na všechny podsítě dostupné na pc - zařízení na něj odpověděla a pak si pomocí binárního protokolu s pc vyměnila pár konfiguračních paketů. Problém nastal, pokud o podsíti počítač nevěděl a posílal konfigurační pakety na výchozí bránu - v případě více síťových zařízení počítače. Pak komunikace nefungovala. Přidání routy na pc problém řešilo, ale to „není dost user friendly“. Samozřejmě to bylo také omezeno na jeden síťový segment, což ale pravděpodobně dostačovalo. Konfigurační aplikace je v JavaFX a je určena primárně pro Windows.

Koukal jsem na Universal Plug and Play, Link Layer Discovery Protocol, Cisco Discovery Protocol atd., ale přijde mi to všechno jako kanón na vrabce.

Máte nějaké nápady, jak k problému přistoupit? Je vůbec toto na transportní vrstvě možné? Nejde nějak využít dhcp?

Odpovědi

[Max]

No takhle, s DHCP si lze vystačit. Pokud je dhcp pod palcem, tak přes něj lze poslat na klienta cokoli. Takto se třeba dají nastavovat i IP telefony, kdy jim přes DHCP lze říci např. to, odkud si mají stáhnout konfigurační soubor (vystavený na ftp/http/tftp atd.).
Zdar Max

[OldFrog {Ondra Nemecek}]

V tuto chvíli nevím, zda má konfigurace probíhat v rámci provozní infrastruktury (in-place) nebo zda si to technik nastaví na stole a teprve pak připojí do infrastruktury. Z toho se odvíjí use-case, zatím uvažuju druhou variantu (stůl).

Výhoda je, že routery s DHCP počítají a tak to většinou funguje i přes tu wifi atd. Asi bych mohl spustit na počítači DHCP server, aplikace by ovšem musela mít administrátorská práva.

Varianta 1.: Zařízení by se periodicky dotazovala (což je asi prasárna) a DHCP server by jim mohl posílat textové odpovědi. Tím by probíhala konfigurace bez ohledu na IP a podsítě.

Varianta 2.: Zařízení si při startu přes DHCP nastaví druhou IP pro komunikaci s počítačem technika. Tím pádem by se konfigurační IP ocitla v síti dostupné z pc a mechanismus by fungoval. Ale vidím tam například možnost kolize IP, poněvadž zařízení může mít staticky přidělenou libovolnou IP. Takže konfigurační IP na daném zařízení klidně zkoliduje s tou statickou. Nevím taky jestli je tcp/ip stack na zařízení připraven na více ip adres.

Varianta 3.: Pomocí DHCP nasměrovat zařízení na centrální konfigurační bod (ftp, http, cloud...). To asi nic neřeší, proto k tomu je potřeba konektivita, kterou když máme, můžeme se zařízením komunikovat přímo a jsme u varianty 2.

V každém případě DHCP na počítači technika řeší elegantně i discovery - DHCP server zná své svěřence. Ten protokol je navíc na konfiguraci určený a všeobecně podporovaný. To je plus.

[Jendа]

Problém nastal, pokud o podsíti počítač nevěděl a posílal konfigurační pakety na výchozí bránu

Já tohle teda nikdy nedělal, ale když pošleš na 255.255.255.255, tak se to pošle broadcastem a nic jiného nemusíš vědět, ne? Nebo si najdi jak funguje DHCP požadavek od DHCP klienta a udělej to takhle. Nevím jestli k něčemu z toho není potřeba root.

Samozřejmě to bylo také omezeno na jeden síťový segment

To bude vždycky, nemůžeš poslat broadcast do neznámé sítě jinde, a asi nemáš moc jiných způsobů, jak tam neznámé zařízení oslovit.

[OldFrog {Ondra Nemecek}]

Já tohle teda nikdy nedělal, ale když pošleš na 255.255.255.255, tak se to pošle broadcastem a nic jiného nemusíš vědět, ne?

Ano, tak to dělám, posílám na podsítě a pak ještě genericky na 255.255.255.255. Pak posbírám odpověďi a mám seznam zařízení. Takže discovery jakž takže funguje. Ne úplně vždy, u některých switchů nebo soho routerů v bridge režimu asi zafunguje nějaký mechanismus (icmp? arp? - nemám tušení) a odpověď na broadcast nedorazí (nevidím ve wiresharku). Tento problém je asi samostatná kapitola. Ještě mám pochybnosti ohledně wifi - pokud je pc připojen k wifi routeru opět v bridge režimu a do toho routeru jsou připojená ta zařízení, tak to někdy nefunguje. Kvůli těmto komplikacícm mi to přijde hrozně fragilní řešení, které je hádám dost závislé na kvalitě toho "routeru". Poměrně blbě se to testuje. Tester píše:

Pokud bylo zařízení připojena do ETH na switchi a notebook s utilitou na WLAN do stejného switche, zařízení nebylo nalezeno. Když obojí na ETH, tak ano.

Co však principiálně nefunguje je odeslání konfiguračního paketu specificky na to jedno konkrétní zařízení. V té konfigurační aplikaci je tlačítko "nastav to a to" - uživatel vybere zařízení, stiskne to tlačítko a aplikace odesílá paket na vybrané zařízení. Jenže pokud pc nemá správnou routu na tu podsíť, tak paket do zařízení nedorazí.

Jedině že bych konfigurační pakety taky broadcastoval a zařízení by si sama pakety přebrala a reagovala jen na pakety určené pro ně. Aplikace by shromáždila všechny odpovědi a z toho určila, zda se konfigurace povedla (zařízení konfigurační paket potvrzují). Má takový postup nějaká úskalí?

[Jendа]

Co však principiálně nefunguje je odeslání konfiguračního paketu specificky na to jedno konkrétní zařízení.

Aha, tak to by (jako zjednodušení pro uživatele) měla mít aplikace jednoduchou možnost přidat chybějící routu (třeba defaultně zapnutou, ale mělo by to jít vypnout pro pokročilé uživatele). Další možnost je ten paket vyrobit a poslat ručně přímo na to zařízení přes něco jako scapy, ale to je asi zbytečně komplikované, a až někdo přijde s tím, že mu nestačí jednotlivé pakety, ale chce mít skutečné spojení, tak bys efektivně reimplementoval IP stack ve svém programu, a to nechceš.

To s tou propagací přes wifi nevím, ale překvapuje mě to, protože jsem ještě nikdy nenarazil na žádnou záhadnou nefunkčnost DHCP, a to by mělo fungovat přesně takhle.

[ehmmm]

Ten napad s posilanim konfigurace pres broadcast je sice netradicni, ale me se libi. Kdyz uz to zarizeni jednou na broadcast odpovedelo, tak lze predpokladat, ze k nemu dorazi i ten konfiguracni boradcast a ukol je splnen.

Samozrejme si musis nejak osetrit, abys omylem neprekonfiguroval neco jineho.

[Jar-Jar Blinks]

 
Jestli chapu spravne ? mate jeden ethernet, na nem nezname Ip site ?
 .... a chcete se bavit s devicem ktereho neznate IP adresu,subnet,gw --->

#------------------------------------------------------------------------------
a) neresit to jako IP, ale na L2 .... poslat paket na broadcast ffff.ffff.ffff
     a device odpovida taky broadcastem kde v eth payloadu posila dohodnute
     informace...

b) ...multicast adresace...
     zkuste se podivat jak to resi treba protokol ospf, hsrp, eigrp ....
    

c) nebo je uplne optimalni pouzit IPV6 a local link adresaci ...
     ... a navic mate i do budoucna vystarano 

d) kdyz uz jsme u IPV6 tak by to i pri routingu tj neni to 
     jeden segment resila anycast adresa ....

e) asi by se dalo jeste neco vydumat ???
#----------------------------------------------------------------------------
a) -> cunarna
b) -> blbe by se to prenaselo do WAN prostredi, ale jde to.
c) -> ciste,perspektivni -> ale je to omezene na eth segment
      a nevyzaduje IPV6 od infrastruktury, nemelo by mit problemy s proxy-arpem
      
d) -> ciste, routovatelne, a perspektivni.... nutne mit implementovano IPV6

toz tak .... -)