(UDP) Broadcast, Multicast of andere (betere) manier?

[Atmoz]

Beste newerkwerkspecialisten,

Op dit moment zou het me goed uitkomen als ik iets meer had onthouden van m'n Netwerk Infrastructuur Design opleiding

Het probleem is als volgt:

Ik heb 2 wireless devices (waarvan 1 Android smartphone) die beide netjes een IP-adres gekregen hebben van de(zelfde) router.
Beide hangen dus aan hetzelfde Wifi-netwerk en moeten straks met elkaar gaan communiceren.
(Op dit moment lukt dat nog niet, want ze weten elkaars IP-adres niet...)

Om dit op te lossen had ik bedacht dat als device-A zou opstarten, hij het (dan verkregen/iedere keer eventueel nieuwe) IP-adres middels een UDP-broadcast (naar 255.255.255.255 dus) kenbaar zou maken aan device-B. Deze stuurt vervolgens via een WebRequest zijn eigen IP-adres mee zodat device-A hier ook van op de hoogte is. Vanaf nu weten beide devices elkaars IP, en werkt alles goed (als voorbeeld even 192.168.1.2 en 192.168.1.3)

Het probleem is dat broadcasten naar 255.255.255.255 lang niet altijd ondersteunt wordt door routers.

Daarom heb ik ook naar multicast gekeken.
Op device-A (192.168.1.2) stuur ik dan naar 192.168.1.255 zodat device-B (192.168.1.3) dan ook de hoogte is. Dit heb ik allemaal al gemaakt en getest. Alleen nu ben ik dus iets verder gaan zoeken en blijkt vervolgens dat voor multicast IGMP nodig is. Iets dat hier thuis (blijkbaar) wel gewoon aan staat, maar dat ook dit lang niet altijd bij alle routers het geval is.

Als alternatief wilde ik mDNS gebruiken, maar dit wordt helaas niet (meer) ondersteunt op Android.

Ik ben dus eigenlijk door alles opties heen.

Toch zou ik het vreemd vinden als anno 2022 dit nog niet eens -op de een of andere manier- mogelijk is?

Dus wie heeft hiervoor dé oplossing?

[Silver7]

Beide hebben IP-adres gekregen? Ja dus.

Maar waarvoor moet de device A communiceren met device B?

[ Voor 53% gewijzigd door Silver7 op 08-08-2022 14:14 ]

[Atmoz]

Silver7 schreef op maandag 8 augustus 2022 @ 14:14:
Beide hebben IP-adres gekregen? Ja dus.

Maar waarvoor moet de device A communiceren met device B?

Gewoon, die moeten met elkaar praten Dat is de toepassing die ik gemaakt heb.

[ Voor 35% gewijzigd door Atmoz op 08-08-2022 14:15 ]

[Mijzelf]

Je haalt dingen door elkaar. Zenden naar 255.255.255.255 en 192.168.1.255 zijn allebei broadcasts, alleen is de eerste naar een /0 netwerk, en de andere naar een /24 netwerk.
Multicast en IGMP gaan over een andere IP range (244.0.0.0/8)

Bij wifi AP's kun je soms 'client isolation' aanzetten, in welk geval de clients niet met elkaar kunnen praten. Daar kom je niet omheen (of dat is een bug). Anders zouden beide versies van broadcast moeten werken, volgens mij.

[Atmoz]

Mijzelf schreef op maandag 8 augustus 2022 @ 15:46:
Je haalt dingen door elkaar. Zenden naar 255.255.255.255 en 192.168.1.255 zijn allebei broadcasts, alleen is de eerste naar een /0 netwerk, en de andere naar een /24 netwerk.
Multicast en IGMP gaan over een andere IP range (244.0.0.0/8)

Hmzzz ok, ik dacht (meerdere malen) gelezen te hebben dat de 192.168.1.255 "variant" echt Multicast was. Want: niet naar ALLE adressen, maar wel naar vele (multi).

Bij wifi AP's kun je soms 'client isolation' aanzetten, in welk geval de clients niet met elkaar kunnen praten. Daar kom je niet omheen (of dat is een bug). Anders zouden beide versies van broadcast moeten werken, volgens mij.

Klopt het dan niet wat ik zo hier en daar lees dat veel routers 255.255.255.255 niet doorlaten?

Welke van de 2 smaken zou ik dan nemen? De 255.255.255.255 of de "berekende" 192.168.1.255 (in dit geval).

[Aragnut]

Als de apparaten altijd binnen hetzelfde subnet zouden zitten, dan zou ik verkeer zo veel mogelijk limiteren om load zo laag mogelijk te houden. Het naar meer sturen dan waar je zoekt heeft geen toegevoegde waarde.

[Ryanirin]

Kun je ze geen statische lease geven, als het om 2 specifieke devices gaat? Dat lijkt me een stuk praktischer.

[Atmoz]

Aragnut schreef op maandag 8 augustus 2022 @ 15:53:
Als de apparaten altijd binnen hetzelfde subnet zouden zitten, dan zou ik verkeer zo veel mogelijk limiteren om load zo laag mogelijk te houden. Het naar meer sturen dan waar je zoekt heeft geen toegevoegde waarde.

Ja precies. Dit was exact ook mijn gedachte, want daarmee doel je neem ik aan op de "192.168.1.255"-variant, right?

Ik vroeg het eigenlijk ook meer vanwege de compatibiliteit van de meeste routers.


[edit]

Ryanirin schreef op maandag 8 augustus 2022 @ 15:57:
Kun je ze geen statische lease geven, als het om 2 specifieke devices gaat? Dat lijkt me een stuk praktischer.

Ik heb voor de eenvoud (het principe komt natuurlijk op hetzelfde neer ) maar even 2 devices genomen, maar in real life zijn het er 8 ofzo.

[ Voor 26% gewijzigd door Atmoz op 08-08-2022 16:00 ]

[Mijzelf]

Atmoz schreef op maandag 8 augustus 2022 @ 15:52:
Klopt het dan niet wat ik zo hier en daar lees dat veel routers 255.255.255.255 niet doorlaten?

Definieer doorlaten. Theoretisch zou die broadcast naar het hele internet moeten. En nee, normaal gesproken zal een router deze broadcast niet doorsturen naar zijn WAN. Maar binnen de LAN zou ik geen problemen verwachten.

[Atmoz]

Mijzelf schreef op maandag 8 augustus 2022 @ 16:01:
[...]

Definieer doorlaten. Theoretisch zou die broadcast naar het hele internet moeten. En nee, normaal gesproken zal een router deze broadcast niet doorsturen naar zijn WAN. Maar binnen de LAN zou ik geen problemen verwachten.

Haha, ja das een goeie!

Uhm tja, het hoeft inderdaad alleen binnen de LAN natuurlijk

[borft]

Broadcast betekent naar alle adressen in het subnet. Als je netwerk dus 192.168.1.0/24 is, dan is 192.168.1.255 het broadcast adres. Berichten daarnaartoe moeten naar alle devices in dat netwerk (LAN) gaan, en gaan dus niet via de router.

Broadcasts werken ook alleen in het lokale netwerk, en worden nooit gerouteerd. Een andere oplossing is bv een broker gebruiken.

[Ben(V)]

Er is geen enkele router in de wereld die geen broadcast ondersteund.
En multicast is gewoon een vorm van broadcasting.

Alleen is het een onzinnige manier om te bereiken wat je wilt.
Met twee devices zal dat geen probleem opleveren maar dit is wel de beste manier om een broadcast storm te genereren.

Zorg er gewoon voor dat je devices altijd hetzelfde ip-adres krijgen door in de dhcp server van je router een mac-adres/ip-adres koppeling te maken.

Eventueel kun je ook gewoon communiceren door middel van device namen, die kun je gewoon in je router vinden.
Als laatste kun je ook nog gewoon het subnet gaan pollen, tot je een ip-adres hebt gevonden die antwoordt geeft.

[jadjong]

Tenzij het elke keer acht nieuwe apparaten zijn zou ik lekker de ip-adressen vast zetten in de DHCP tabel.

[laurens0619]

Autodiscovery is toch niet zo gek?
Zo werkt chromecasr/apple tv/sonos etc ook

Basis is idd mdns en zover ik lees werkt dit ook op android: https://www.androidpolice...-mdns-local-hostname/amp/

Of je pakt een custom lib
https://github.com/andriydruk/RxDNSSD

Ik zou iig niet zelf zaken coden maar zoveel mogelijk obv mdns doen

[Atmoz]

borft schreef op maandag 8 augustus 2022 @ 16:07:
Broadcast betekent naar alle adressen in het subnet. Als je netwerk dus 192.168.1.0/24 is, dan is 192.168.1.255 het broadcast adres. Berichten daarnaartoe moeten naar alle devices in dat netwerk (LAN) gaan, en gaan dus niet via de router.

Broadcasts werken ook alleen in het lokale netwerk, en worden nooit gerouteerd.

Thanks voor de info!

Een andere oplossing is bv een broker gebruiken.

Had ik inderdaad ook even aan gedacht, maar dan ben ik weer verplicht om internet te hebben op beide devices...

Ben(V) schreef op maandag 8 augustus 2022 @ 17:36:
Er is geen enkele router in de wereld die geen broadcast ondersteund.
En multicast is gewoon een vorm van broadcasting.

Ok, dat is mooi om te weten. Thanks

Alleen is het een onzinnige manier om te bereiken wat je wilt.
Met twee devices zal dat geen probleem opleveren maar dit is wel de beste manier om een broadcast storm te genereren.

Zorg er gewoon voor dat je devices altijd hetzelfde ip-adres krijgen door in de dhcp server van je router een mac-adres/ip-adres koppeling te maken.

Eventueel kun je ook gewoon communiceren door middel van device namen, die kun je gewoon in je router vinden.
Als laatste kun je ook nog gewoon het subnet gaan pollen, tot je een ip-adres hebt gevonden die antwoordt geeft.

Nee, dat laatste is allemaal niet mogelijk.
Het is voor in een "real life omgeving" en niet alleen voor bij mij thuis

jadjong schreef op maandag 8 augustus 2022 @ 17:57:
Tenzij het elke keer acht nieuwe apparaten zijn zou ik lekker de ip-adressen vast zetten in de DHCP tabel.

Zie hierboven, dit is dus niet mogelijk.

laurens0619 schreef op maandag 8 augustus 2022 @ 19:02:
Autodiscovery is toch niet zo gek?
Zo werkt chromecasr/apple tv/sonos etc ook

Basis is idd mdns en zover ik lees werkt dit ook op android: https://www.androidpolice...-mdns-local-hostname/amp/

Of je pakt een custom lib
https://github.com/andriydruk/RxDNSSD

Ik zou iig niet zelf zaken coden maar zoveel mogelijk obv mdns doen

Helaas werkt mDNS écht niet op Android.
Ik heb hier een Samsung S10+ en een Samsung S21 naast me liggen, en op beide werkt het niet.
Dat komt overeen met wat ik her en der erover lees: overal smeekt men om het (weer*) te laten weken op Android...

*het heeft schijnbaar wél (even ) gewerkt!

[Ben(V)]

Als polling niet mogelijk is dan is broadcasting ook niet mogelijk.

Een broadcast blijft ook beperkt tot het subnet, dus je kunt net zo makkelijk even alle 255 adressen van het subnet pollen tot je een antwoordt krijgt.

En mDNS is bagger en werkt niet universeel goed door gebrek aan ondersteuning/implementatie op de verschillende platformen.

[ Voor 22% gewijzigd door Ben(V) op 09-08-2022 20:15 ]

[Atmoz]

Ben(V) schreef op dinsdag 9 augustus 2022 @ 20:13:
Als polling niet mogelijk is dan is broadcasting ook niet mogelijk.

Hoe bedoel je dat precies?

Een broadcast blijft ook beperkt tot het subnet, dus je kunt net zo makkelijk even alle 255 adressen van het subnet pollen tot je een antwoordt krijgt.

Dat een broadcast zich beperkt tot (alleen) het subnet is niet erg aangezien beide devices aan dezelfde Wifi-router (en dus hetzelfde subnet) hangen. Nu er hier gezegd wordt dat broadcast toch ALTIJD (met alle routers op de wereld dus) zou moeten werken, ga ik daar denk ik mijn hoop op vestigen

[edit]

Ben(V) schreef op dinsdag 9 augustus 2022 @ 20:13:
En mDNS is bagger en werkt niet universeel goed door gebrek aan ondersteuning/implementatie op de verschillende platformen.

Dat vind ik best jammer, want met een iPhone die hier ligt werkt het bijvoorbeeld wel super goed
Als mDNS overal zou werken zou dat toch wel een hele fijne oplossing zijn

[ Voor 23% gewijzigd door Atmoz op 09-08-2022 20:18 ]

[laurens0619]

@Atmoz volgens dat artikel zit het net in android, reputatie van android en software updates is beroerd…

heb je ook die github link gelezen?
Lijkt mij prima library om als alternatief te gebruiken

Ook de uitleg is t lezen waard
https://andriydruk.com/post/mdnsresponder/

[ Voor 16% gewijzigd door laurens0619 op 09-08-2022 20:20 ]

[Ben(V)]

Waarom denk je dat polling niet werkt?
Je kiest een poort en test gewoon alle ip-adressen:poortnummer van het subnet tot je antwoordt krijgt en je laat de devices die waar je connectie mee wilt krijgen gewoon op die poort luisteren of er iets binnenkomt en geeft dan antwoordt.
Het zijn letterlijk maar een paar regels code om zo iets te schrijven.

Broadcasten moet je niet aan beginnen.
Een broadcast komt nooit gegarandeerd aan en als je dat probeert op te vangen loop je het risico een broadcaststorm te ontketenen en zo je netwerk plat te gooien.

[laurens0619]

Ben(V) schreef op dinsdag 9 augustus 2022 @ 20:24:
Waarom denk je dat polling niet werkt?
Je kiest een poort en test gewoon alle ip-adressen:poortnummer van het subnet tot je antwoordt krijgt en je laat de devices die waar je connectie mee wilt krijgen gewoon op die poort luisteren of er iets binnenkomt en geeft dan antwoordt.
Het zijn letterlijk maar een paar regels code om zo iets te schrijven.

Broadcasten moet je niet aan beginnen.
Een broadcast komt nooit gegarandeerd aan en als je dat probeert op te vangen loop je het risico een broadcaststorm te ontketenen en zo je netwerk plat te gooien.

Stel je nu echt ver om vanuit software een horizontale port scan te doen tbv host discovery?
Broadcast is niets mis mee en hoezo zou het niet werken? Dhcp is toch ook gewoon broadcast?

[Ben(V)]

Misschien begrijp ik het verkeerd, maar ik begreep eruit dat hij met een app bezig was die met elkaar moeten communiceren en elkaar dus moeten vinden.

Als je dat met een broadcast doet weet je nooit of het aankomt en moet dus blijven broadcasten tot je een antwoordt krijgt en dat moet dus met grote intervallen anders krijg je een broadcast storm.
Als meerdere device dat doen wordt het helemaal een probleem.

En een portscan is alle poorten scannen, hier kies je gewoon een poort.
Dit is gewoon equivalent met maximaal 255 keer een ping, maar in de praktijk veel minder.

[laurens0619]

@Ben(V) nee dat is een verticale port scan, horizontaal is alle ips op 1 poort

Een broadcast storm krijg je niet omdat iedere client bv iedere x minuten discovery doet maar is een broadcast storm typisch iets wat bv bij een netwerklus hoort

Als het zon groot probleem zou zijn dan zou dhcp ook voor geen meter werken

Als je zoveel mogelijk op mdns/bonjour leunt dan zal t wel goedkomen.
Maar dit topic is meer iets voor software development dan netwerken

[ Voor 6% gewijzigd door laurens0619 op 09-08-2022 21:51 ]

[sig69]

Niks mis met een broadcast om clients te ontdekken, zo vaak gedaan. Bericht eruit: "is er iemand?", antwoord: "ja mijn ip is xxx", verbinden maar. Moet je niet elke seconde doen natuurlijk, maar op een redelijke manier.