Kein UDP-Empfang unter Windows Server 2012

[Hobbycoder]

Hi,

ich habe eine Client<->Server-Anwendung, welche Daten per UDP-Broadcast austauschen soll (Quasi: Client sendet "Hallo" und Server antwortet z.B. mit seiner IP), damit der Client den Server automatisch findet.
Lokal, also Client und Server auf der gleichen Maschine läuft das problemlos. Vom Server zum Client auch. Aber wenn der Client zum Server was schicken soll, dann kommt da nichts an.

Weiß einer ob es da unter Windows Server 2012 irgendwelche Bugs gibt, oder man erst irgendein Feature installieren muss, damit das funktioniert?
Der Server hat 2 physikalische LAN-Ports, wobei nur einer genutzt wird. Weiterhin hat eine vEthernet-Schnittstelle für den Hyper-V-Switch und eine AVM-B1-ISDN-Karte.

Der Fehler könnte auch noch mit anderen BS auftreten, da bin ich noch am testen. Lieder habe ich zur Zeit nicht so viele Maschinen hier zum testen.

[Klaus01]

Hallo,

Firewall - die entsprechenden Ports geöffnet?
Mit Wireshark geschaut ob die Packete am Server ankommen?

Grüße
Klaus

[Hobbycoder]

Ja, vergessen zu schreiben.

Firewall ist beidseitig aus. Und das ganze habe ich mit Wireshark auch schon überprüft. Beim Windows 2012 Server kommt definitiv nichts an, Broadcast schicken kann er aber problemlos, was man auch im Wireshark sehen kann.

[Klaus01]

.. das sieht dann so aus als wenn der Client nichts schicken würde?
Die Pakete verschwinden ja eigentlich nicht einfach so von der Leitung.

Was sagt denn Wireshark beim Client?

Grüße
Klaus

[HolgerX]

Hmm..

Welcher BroadCast ist es denn?

255.255.255.255 wird seit einigen Windows-Versionen (W7+) von Windows geblockt.
Es geht nur noch ein BroadCast im eigenen SubNet (z.B. 192.168.0.255).

Also, vor Versenden anhand der Netzwerk-Karte das SubNet ermitteln und dann nur in dessem BroadCast senden.

[Aviator]

Zitat von HolgerX:

Hmm..

Welcher BroadCast ist es denn?

255.255.255.255 wird seit einigen Windows-Versionen (W7+) von Windows geblockt.
Es geht nur noch ein BroadCast im eigenen SubNet (z.B. 192.168.0.255).

Also, vor Versenden anhand der Netzwerk-Karte das SubNet ermitteln und dann nur in dessem BroadCast senden.

Und wie funktioniert das bei /16 bzw /8 Netzen? Funktioniert dann 172.16.255.255 bzw. 10.255.255.255?

[HolgerX]

Hmm..

Weiß nicht..

Kann aber auch hieran liegen:

https://serverfault.com/questions/72...ior-on-windows

http://www.mcseven.me/2011/01/window...dcast-cloning/

[Hobbycoder]

So, nach kurzer, kundenbedingter Arbeitspause, kann ich mich wieder mit meinem Problem beschäftigen.

Ich habe jetzt einige Test gemacht. Mit dem Ergebnis, dass nicht der Windows 2012 Server die UDP-Broadcast nicht reinlässt, sondern mein Windows 10 Rechner die UDP-Broadcast nicht raus.
Bei genauerer Betrachtung dachte ich mir ich schau mir mal das Routing an. Da ich auch dort einen Hyper-V am laufen habe, ebenfalls mit einem virtuellem Switch, stelle ich fest, dass 3 Broadcast Adresse das sind. Die Loopback, die physikalische LAN-Verbindung und die vom virtuellen Switch.
Nach dem ich die Netzwerkverbindung von dem virtuellen Switch deaktiviert habe, funktioniert jetzt mein Broadcast perfekt.

So, nun muss ich aber damit rechnen, dass beim Kunden doch mal eine ähnliche Konstellation auftaucht und entsprechend darauf reagieren. Da ich mit dem TIdUDPClient arbeite, muss ich halt bei solchen Fällen die Broadcast-Adresse mit übergeben, da sonst Standardmäßig 255.255.255.255 verwendet wird. Das werde ich dann jetzt auch mal ausprobieren.

[HolgerX]

Hmm..

Schau Dir doch mal meine Links an, anscheinend gillt das von W7 auch für W10.

Dort sind eine Art Muliplexer-Programme verwendet, mal als Dienst, mal als AdminApp...

Bei einem Link gab es sogar den Source (c++), wie die BroadCasts an verschiedene Netzwerk-Adapter korrekt verschickt werden..

[Hobbycoder]

Hab ich mir angesehen. Aber Broadcast clonen ist mir zu aufwendig. Und ich kann auch nicht von den Usern erwarten, dass die noch ein weiteres Programm installieren.

Ich habe das jetzt erst mal so gelöst, dass ich dem User die Möglichkeit gebe eigene Broadcast-Adressen zu hinterlegen. Klappt also der automatische Broadcast über 255.255.255.255 nicht, so kann er passende (z.B. 192.168.0.255 und 192.168.1.255) hinterlegen. In dem Fall sende ich den Broadcast halt zweimal. Ich denke für das was ich erreichen wollte reicht das aus.
Bei den ersten Tests hat das schon mal recht gut funktioniert. Weiter Tests folgen.