Windows 7 und alte Games: UDP-Broadcast-Cloning (Update)

Inhaltsverzeichnis

 

1. Vorwort Inhalt

Gerne erinnern wir uns an die Zeiten unserer Jugend, nicht daß die schon vorbei wären 😉 , und denken dabei auch an die unzähligen LAN-Parties oder LANs zurück, auf denen nächtelang gezockt wurde bis die Augen zufielen. An Genres kam alles dran, vom Killerspiel bis zur Materialschlacht in der C&C-Reihe.

Der hier beschriebene Blogeintrag entstand, nachdem ein paar Kollegen diese Zeiten wieder aufleben lassen wollten, und mit modernen Versionen der Betriebssysteme und den guten alten Games Schwierigkeiten haben.

2. Problem Inhalt

Konkret geht es um das Spiel Warcraft 3, auf dem wir Tower Wars 1.1 zocken („Türmchen bauen“). Wir haben dabei die Schwierigkeit, daß das Hosten auf Windows Vista und Windows 7 einfach nicht funktioniert, wenn wir die Rechner über OpenVPN zusammenschließen. Partout erkennt niemand das Spiel im Netzwerk, wenn es auf einem der beiden Betriebssysteme erstellt wird. Ein Kollege hat noch XP (den Gameloader, wie er es nennt), dort läuft es einwandfrei und 7er können auch beitreten.

3. Symptome Inhalt

Es scheinenen mehrere Voraussetzungen und Gegebenheiten erfüllt zu sein:

  • Betriebssystem ist Windows 7 oder Vista.
  • Es existiert mehr als ein physischer Netzwerkadapter (z.B. Open-VPN TAP Device).
  • Die Rechner befinden sich mit einem dieser Netzwerkinterfaces in einem gemeinsamen Subnetz (10.10.12.[4-10]).
  • Routing funktioniert, Pingen lassen sich die Maschinen untereinander.
  • Latenzen sind akzeptabel, sprich <200ms.
  • Firewalls sind ausgeschaltet, sprich deaktiviert, nicht nur mit Ausnahmen versehen.

Es gibt also keinen Grund, warum die Konfiguration für die Kommunikation zwischen den Rechnern für Warcraft 3 nicht ausreichen sollte.

4. Hintergrund Inhalt

Nach nächtelangem Suchen im Internet stieß ich auf die Lösung. Warcraft 3 benutzt zum Ankündigen eines offenen Spiels im LAN UDP-Broadcasts. Hat ein Rechner nur eine Netzwerkkarte, so ist alles in Butter: Das Paket geht nur über diese Schnittstelle raus und wird eben im Subnetz verteilt.

Existieren 2 oder mehr Interfaces, bekommen wir ein Problem: Dann werden die Broadcasts nur noch auf der Verbindung mit der niedrigsten Metrik ausgegeben, also meistens auf einer einzigen Netzwerkkarte.

Nun ist es unter XP so, dass die Open-VPN-TAP-Schnittstelle, wenn die automatische Metrik aktiviert ist, höchste Priorität erhält, vielleicht weil dort die Metrik automatisch anders geändert wird (OpenVPN meldet einen 10 MBit/s Linkspeed bei Windows). Unter Vista und 7 allerdings ist das nicht mehr der Fall. Dort bleibt wahrscheinlich die Netzwerkkarte mit der dicksten Datenrate die höchstpriorisierte Verbindung.

Wir sehen schon, die Fehlfunktion liegt daran, daß die „Announce“-Pakete auf dem falschen Interface ausgegeben werden, und statt ins VPN über die lokale Netzwerkkarte wegen der geringeren Metrik der Verbindung gesendet werden.

Es scheint generell eine Schwierigkeit zu geben, wenn Programme in guter Intention auf 255.255.255.255 broadcasten in der Hoffnung, wirklich alle angeschlossenen Netze zu erreichen, das Betriebssystem aber tatsächlich eben nur auf dem einen Interface mit geringster Metrik sendet.

5. Lösung Inhalt

Gelöst werden könnte das Problem auf mehrere Arten.

5.1 Saubere Programmierung Inhalt

In der eigenen Software müßte man alle verbundenen Netzwerke abfragen und an ihre jeweilige Broadcast-Adresse schicken. Die Broadcast-Adresse ist die Adresse mit lauter 1-Bits im Host-Teil, bei /24er (Class C) Netzen also *.*.*.255, bei /16 (Class B) *.*.255.255 und bei /8 (Class A) Netzen *.255.255.255; siehe auch hier.

Das läßt sich auf Warcraft 3 leider nicht anwenden, da das Spiel an 255.255.255.255 sendet.

5.2 Routen ändern Inhalt

Für die Dauer des Spiels könnte man alle Routen an 255.255.255.255 löschen und nur eine einzige auf die jeweilige VPN-Adresse setzen; auf der Kommandozeile ist einzugeben:

5.3 Metrik ändern Inhalt

Man könnte die Metrik der Verbindungen für alle Einträge 255.255.255.255 auf den gleichen Wert setzen. Theoretisch möglich sein sollte das, zumindest habe ich das in der Routingtabelle schon gesehen. Leider spinnt der ROUTE ADD Befehl, und hält sich nicht an meine Metrik-Vorgaben unter Windows 7 x64. Aus METRIC 10 werden dann mal 40 und mal 20, ich hab’s nicht hinbekommen.

5.4 UDP-Pakete klonen Inhalt

Ein findiger Programmierer hat sich ein kleines Tool geschrieben, dass jede Netzwerkkarte im Promiscous-Mode öffnet mittels WinPCap, und einfach lokal erzeugte UDP-Broadcasts auf allen nicht betroffenen Netzwerken ausgibt und dabei die Quell-IP-Adresse noch korrekt setzt (Port bleibt natürlich erhalten wie er war).

Das Tool muß im Administrator-Modus gestartet werden und hinterläßt keine Spuren im System. Ich persönlich halte das für die brauchbarste Lösung, weil man nicht selbst mit den unberechenbaren Routingtabellen spielen muss.

Update: Es existiert offenbar noch ein weiteres Tool (HamachiBroadcastFix), dass vergleichbares leistet und für die VPN-Lösung Hamachi geschrieben wurde. Den Blogeintrag findet ihr hier (Danke an dere24), weiter unten auf der Seite findet sich eine Beschreibung und der Download.

9 Kommentare zu “Windows 7 und alte Games: UDP-Broadcast-Cloning (Update)”

1.   Kommentar von dere24
Erstellt am 24. Januar 2011 um 10:43 Uhr.

Hallo.

Meine Frage: Hat es mit dem UDPPort-Forwarder funktioniert Warcraft III zu speielen. Bei mir hat es über zwei XP-Rechner keine Probleme gegeben.
Jedoch der Rechner mit Win 7 konnte das Spiel nicht finden, auch nicht mit UDPPF. Ich werde nochmals meine OpenVPN-Config überprüfen ob ich UDP oder TCP-Port verwende. Oder spielt das überhaupt eine Rolle?

mfg dere24

2.   Kommentar von McSeven
Erstellt am 24. Januar 2011 um 14:52 Uhr.

Grüße, also ja, hat funktioniert.
@UDPPF: Der UDPPF müßte eigentlich nur auf dem hostenden Rechner laufen.
@OpenVPN: TCP oder UDP ist egal, hat beides funktioniert, zuletzt lief UDP.

Lass zur Sicherheit einmal auf dem Win 7 das Tool laufen und schau im unteren Teil des Fensters, dort stehen ankommende Broadcasts von anderen Maschinen. Wenn Du auf XP ein Spiel aufmachst, sollten hier auf Win 7 Pakete der XP-Maschine angezeigt werden und auch die Pingzeit.

Zur Not Tool auf Win 7 starten und dort hosten.

Wenn das nicht geht, kannst Du noch probieren, die OpenVPN und Netzwerkadapter Schnittstellenmetrik auf der Win7-Kiste von Hand gleich zu setzen (z.B. „10“). Netzwerverbindungen -> Adaptereinstellungen -> Eigenschaften -> TCP/IPv4 -> Erweitert -> „automatische Metrik“ aus und „10“ ins Feld drunter eintragen bei beiden Adaptern.

Und ganz auf blöd: Firewall ist aus, nicht wahr…

3.   Kommentar von Hannes
Erstellt am 28. Januar 2011 um 22:38 Uhr.

Hallo,
bin der Programmierer von dem Tool. Wir spielen WC3 auch damit. Nutze selbst Win7. Die Anderen mit denen ich spiele haben XP und Vista. Funktionierte bei allen bisher.
Die Liste der Broadcaster ist nicht „immer“ aktuell. Am besten immer im Spiel direkt testen.
Es dauert unter umständen etwas bis das Spiel gefunden wird. Aus dem Grund, das nicht alle Broadcasts immer weitergeleitet werden um Floods zu vermeiden.
Zu OpenVPN: Ich würde das mit UDP benutzen. TCP bremst zu sehr. Da der getunnelte Verkehr in der Regel dann eh über TCP läuft hat man auch keine Probleme mit evtl. verlorenen Paketen.
Falls du weiterhin Probleme hast kann ich dir empfehlen mal WireShark zu installieren. Damit kannst du auf den entsprechenden Adaptern Sniffen und siehst direkt ob Daten für Warcraft ankommen. Falls das nicht der Fall ist, dann kannst du auch mit Wireshark am Host-Rechner guckn ob dort die Daten ins VPN geleitet werden. Einfach nach UDP Paketen filtern.

Viel Erfolg und viel Spaß mit den Klassikern.

Gruß…

4.   Kommentar von dere24
Erstellt am 31. Januar 2011 um 14:42 Uhr.

Hallo,

@hannes: ich habe dein Tool getestet, aber wie gesagt ohne die erhoffte Lösung des Problems. Vllt. habe ich einfach zu wenig lange gewartet.

Ich bin aber auf eine Alternative gestoßen.
HamachiBroadcastFix (funktioniert nicht nur mit Hamachi) macht eigentlich genau das was ich will. Eigentlich hätte es einfach Broadcast Fix oder so lauten können.

http://www.espend.de/artikel/gameserver-ueber-hamachi-tunngle-und-co-werden-windows-7-nicht-angezeigt.html

Unter diesem Link gibt es sogar eine weitere Version mit grafischer Oberfläche. Somit lässt sich alles spielend einfach einstellen.
Funktioniert also bei mir in Verbidnung mit OpenVPN einwandfrei.

mfg
dere24

5.   Kommentar von McSeven
Erstellt am 31. Januar 2011 um 14:57 Uhr.

hm, würde mich sehr wundern, weil beide Programme offenbar vergleichbares leisten. Ich kann nur nochmal auch vom Wochenende her bestätigen, dass es völlig ohne Änderung an den Routing-Tabellen ausreicht, auf der hostenden Maschine UDPPF auszuführen. Danke trotzdem für den Link, hab den Artikel upgedated… Cheers, Christoph

6.   Kommentar von speaker
Erstellt am 27. Juli 2012 um 22:29 Uhr.

Ich habe mich gerade mit der gleichen Problematik beschäftigt und bin zu folgendem Ergebnis gekommen: Wenn man die Interface-Metrik des TAP-Adapters auf 5 (oder noch kleineren Wert) setzt, bekommen alle Routes, die beim OpenVPN-Verbindungsaufbau gesetzt werden, definitiv kleinere Metriken als bspw. die bestehende LAN-Verbindung. Das trifft dann auch auf die 255.255.255.255/32 zu und UDP-Broadcasts funktionieren ohne weitere Tools oder Einstellungen prima.

Interface-Routen prüfen:
> netsh int ip show int

Interface-Metriken setzen:
> netsh int ip set int metric=5

(Commands jeweils als Admin ausführen)

7.   Kommentar von speaker
Erstellt am 27. Juli 2012 um 22:32 Uhr.

Nachtrag:

Der zweite Command stimmt nicht ganz, die Kommentarfunktion hatte leider meine Tags herausgekürzt. So nun korrekt:

Interface-Metriken setzen:
> netsh int ip set int „NAME DES TAP-ADAPTERS“ metric=5

8.   Kommentar von McSeven
Erstellt am 29. Juli 2012 um 11:56 Uhr.

Grüße, Danke für den Kommentar, Du hast Recht, es funktioniert, wenn Du nur die OpenVPN-Verbindung hast. Leider werden sie dann im LAN nicht mehr verbreitet und die LAN-Clients finden trotzdem nichts… Cheers, Christoph

9.   Kommentar von Kein UDP-Empfang unter Windows Server 2012 - Delphi-PRAXiS
Erstellt am 03. November 2017 um 16:28 Uhr.

[…] […]

Einen Kommentar hinterlassen