Socket UDP Hole Punching bereitet Probleme

[irgendjemand]

wie der titel schon vermuten lässt habe ich probleme mit UDP Hole Punching

wie das ganze an sich funktioniert ist mir klar

A will eine UDP verbindung zu B aufbauen
B's NAT verhindert dies
A kontaktiert public server S und teil diesem mit das er eine verbindung zu B aufbauen will
S reicht diese information an B weiter
B sendet nun UDP pakete an A auf einem bestimmten port den B über S von A erhalten hat
B sendet wiederum seinen port an S der diesen A mitteilt
A sendet nun UDP pakete auf dem entsprechenden port an B

beide NAT erlauben nun eingehenden UDP verkehr von den entsprechenden IP adressen auf dem bestimmten ports ...

soweit die theroie ... die so ja auch bei allen diensten verwendet wird *skype , teamspeak , online spiele*
und das ganze funktioniert auch ansonsten könnte ich solche dienste ja nicht nutzen

ich habe natürlich schon google gefragt und so einige beispiel codes ausprobiert
einige beispiele hatten test-klassen welche einen entsprechenden test zu einem server im netz gemacht haben und lieferten als ergebnis ERFOLG
auch ein in C geschriebener test der TU München lieferte mir beim UDP Hole Punching test ERFOLG ...

im großen und ganzen : sowohl mein system als auch mein router sind fähig für UDP Hole Punching

mein problem :

wenn ich das ganze von meinem rechner aus testen will und versuche mit mir selbst eine UDP session aufzubauen scheitert dies
mitlerweile bin ich zur überzeugung gekommen das dieses problem durch meine router *d-link dir-100* verursacht wird da dieser offenbar probleme damit hat die richtigen daten in die NAT einzutragen bzw die IP-adressen nicht richtig erkennt

eigentlich müssten in meiner NAT zwei einträge stehen
UDP out *local ip*ORT > *public ip*ORT
UDP in *public ip*ORT > *local ip*ORT

doch genau das ist eben nicht der fall

da ich leider nur sehr begrenzte möglichkeiten und weder einen externen server für z.b. STUN noch ein zweites , externes netz mit NAT zur verfügung habe wollte ich mal die genrelle frage stellen :

könnte es wirklich an meinem router liegen und daran das dieser nicht darauf klar kommt das er pakete an sich selbst schicken soll welche als ziel bzw quelle seine public IP haben ?

zum testen habe ich folgenden source verwendet : NAT tunnel using UDP hole punching mehod in Java language Ma?karáda: masquerade.cz - GNU/Linux | TCP/IP sít? | a ostatní… *unten auf DOWNLOAD SOURCE*

wenn jemand lust hat das ganze mal mit mir übers netz zu testen -> ICQ : 345-169-219

wie gesagt : die grundlegende funktionsweise von UDP Hole Punching habe ich verstanden und verschiedene tools bestätigen mir auch das dieses mit meinem netz mit einem externen partner möglich ist ... nur ein test von "innen" scheitert offenbar am router

danke schon mal im vorraus über die zerbrochenen köpfe

*falls weitere infos benötigt : einfach sagen was noch fehlt*

 

[Gast2]

skype

evt. - nutze ich nicht

teamspeak , online spiele

nein - kein Hole-Punching ... wozu auch?? ... Server ist ja da

 

[irgendjemand]

du weist schon das teamspeak nur UDP verwendet ...
TCP würde irgendwann eine zu große verzögerung verursachen ...
und online-spiele ebenfalls ... zumindest wenn du in die richtung ego-shooter *GoldSrc , Source* gehst ...

btw : das worauf du geantwortet hast findet man auch im netz das es eben so ist ... auch rein logisch würde TCP bei den genannten anwendungen völlig fehl am platz sein ...

kurz : deine antwort hat mir exakt NULL weitergeholfen

 

[Kr0e]

Nein, TeamSpeak als auch OnlineSpiele nutzen kein UDP Hole Punching, aber netter Versuch . Wozu auch, wie Mogel schon sagte, es gibt ja einen bekannten Server. TeamViewer hingegen nutzt UDP Hole Punching. Gut, das bringt dich auchb nicht weiter, aber:

Am Router dürfte es nicht liegen, da dieses Verhalten ja gewünscht ist. Der Router denkt ja "hey, da kommt gleich ne Antwort, also warte ich mal" Ein Router der das nicht kann, kann auch kein UDP... Ist ja bei TCP ähnlich, nur dass dort eben ne Bestätigung abgewartet wird, daher ist es bei weitem schwerer als mit UDP. Ich würde dein Programm nochmal logisch durch gehen und alle möglichen Fehlerquellen in Betracht ziehen.

Woran es speiziell liegt ist unmöglich zu sagen ... ohne weiteres Hintergrundwissen. Mit meiner Fritzbox klappt UDP Holepunching... Nie ein Problem gehabt.

 

[mjdv]

du weist schon das teamspeak nur UDP verwendet ...
TCP würde irgendwann eine zu große verzögerung verursachen ...
und online-spiele ebenfalls ... zumindest wenn du in die richtung ego-shooter *GoldSrc , Source* gehst ...

Das stimmt so weit ich weiß nicht so ganz. Für die Bewegungsdaten bzw. alles was schnell gehen muss, und wo auch mal ein Paket verloren gehen darf, wird UDP verwendet, klar. Aber wenn zB ein Spieler kommt oder geht wird das über TCP gesendet, weil man dort genau die Sicherheit braucht ob das Paket angekommen ist oder nicht.

 

[irgendjemand]

hmm ... da muss ich euch beiden aber mal in den rücken fallen ..

sowohl teamspeak2 als auch half-life 1 bauen KEINE TCP zum server auf
ergo : läuft die gesamte verbindung über UDP ... und da kann ja nur ne verbindung über UDP Hole Punching zustande kommen ... ansonsten würde mein router ja mit einfachen DROP auf die pakete reagieren ...

also WENN man schon zu so nem thema seinen senf abgibt sollte man sich damit auch mal etwas tiefgründiger befassen ... kann man sogar ohne wireshark rausfinden ... einfach ne ordentliche firewall die einem sowas anzeigt ...

und wenn es mit der fritz-box so gut funktioniert : dann versuch es doch mal wie ich einfach mit dir selbst ne verbindung aufzubauen ...

 

[Kr0e]

Du hast doch so schön beschrieben, was UDP Hole Punching ist, aber offenbar hast du davon null verstanden. Der Begriff UDP Hole Punching zielt darauf ab, das Verhalten des Routers zu nutzen, um die Verbindung zu einem anderen PC (auhc hinter NAT) zu öffnen. Weder mogel noch ich haben behauptet, dass spiele/ts NICT über UDP laufen. Lesen hilft, wenn man keine Ahnung hat

Und wenn du meinst hilfe zu verlangen, dann bringt es erstens nichts, die Befragten zu beschimpfen und zweitens uninformiert hier DEINEN Senf dazu beizutragen.

Zu Sagen JEDE UDP App benutzt UDP Hole Punching ist schlicht weg falsch.

Achja nur am Rande: TS, HL etc bauen alle noch eine TCP Verbindung auf, darüber werden Befehle geschickt und über UDP die Rohdaten. Das Thema ist für mich hier beendet.

 

[Gast2]

läuft die gesamte verbindung über UDP ... und da kann ja nur ne verbindung über UDP Hole Punching zustande kommen

???:L ... Du hast Null Ahnung und willst nur trollen

 

[irgendjemand]

ja gut ... das z.b. die HL1-engine ne TCP/27015 aufbaut liegt am auth-protocol mit dem sich der client über den auth-server authentifizieren muss ...

aber mach dir mal den spass und sieh dir mal genau an welche verbindungen TS2 offenhält ... bei mir wird selbst über wireshark nur EINE UDP verbindung gelistet *lässt sich ja anhand der ziel-ip filtern*

das mit dem trollen ... hmm ... wenn ich mir so eure planlosigkeit reinziehe ... dann bestimmt ...

und ich habe ganz sicher verstanden auf was udphp abzielt ...

witzig find ich nur das hier kein auf die eigentliche FRAGE eingegangen ist : *zitat* liegt es vllt an meinem router *zitat ende*

da sieht man mal wie ihr trollt

ich mein ... alleine wenn ich mir diese witzlosen fragen im noob-forum gebe wird mir klar : wer sowas überhaupt zulässt muss sich selbst extrem trollen ...

 

[Kr0e]

Lies dir alles nochmal durch und überlege nochmal in Ruhe und iwann verstehst du vlt mal was wir meinen.

 

[bERt0r]

Was hier irgendjemand vielleicht nicht verstanden hat, ist, dass UDP holepunching keine seriöse Methode ist, um eine Verbindung herzustellen. Wenn man sich einen Router einrichtet, möchte man auch, dass zu den Rechnern dahinter keine Verbindungen aufgebaut werden, wenn schon leitet man die Ports weiter oder benutzt upnp.
Kein kein seriöses kommerzielles Produkt - ob man Skype jetzt als seriös ansehen will sei dahingestellt, ich tu's nicht - benutzt meines Wissens nach UDP holepunching.

 

[irgendjemand]

um euch alle jetzt noch mal zu trollen

es geht ... problem lag wirklich daran das mein router es nicht auf die reihe bekommen hat sich selbst zu addressieren ... *s***** teil ... wird ausgetauscht*

habs grad mit nem freund getestet ... er bekommt meine nachrichten und ich seine ... klappt also mit ner externen addresse

und was UDP HP vs UPnP angeht

UDP HP ist wohl die deutlich seriösere methode im gegensatz zu UPnP ... denn UPnP erlaubt es einer software ports nach belieben im router zu öffnen ... UDP HP hingegen ist ja nichts weiter als ein NAT-eintrag ...
beides zwar nicht sicher ... aber es gibt EIN argument was GEGEN UPnP spricht :
nicht alle heute im einsatz befindlichen geräte beherrschen dies *ich rede nicht von neu produzierten sondern von alten noch eingesetzten* ... UDP HP hingegen wird auch noch von älteren modellen unterstützt ...

 

[Kr0e]

Du musst nur bedenken, dass UDP HP definitiv KeepAlive-Signale braucht. Sprich es müssen alle paar Sekunden Daten über die Leitung gehen, sonst schließt der Router iwann den Eintrag und das ist leider Routerabhängig. Sprich wenn bei einem Router ein timeout von 5 min gesetzt ist, liegt es bei einem anderen vlt bei 30 sek. DAs sollte man bei der Proigrammierung beachten. Ich habs damals uach so ähnlich gemachtu nd mich gewundern, warum das Prog bei mir ging aber bei einem Kumpel nicht...

Außérdem ist der größte Vorteil an UPnP das damit auch TCP Ports geöffnet werden können. Ic hgebe dir Recht, bei UDP macht es keinen Sinn... Und ich finde uach ,dass UPnP eine ansich unsichere Sache ist. Besser wäre es, wenn die User sich mal ein wenig mehr mit Technik beschäftigen würden und wissen, wie man Ports von Hand freigibt...

 

[Gast2]

Besser wäre es, wenn die User sich mal ein wenig mehr mit Technik beschäftigen würden und wissen, wie man Ports von Hand freigibt...

so eine Diskussion hatte ich mit einem Kollegen auch mal ... seit dem schraube ich wegen jeder Kleinigkeit selber an meinem Auto rum - gibt ja genügend Bücher für so etwas :rtfm:

 

[Kr0e]

so eine Diskussion hatte ich mit einem Kollegen auch mal ... seit dem schraube ich wegen jeder Kleinigkeit selber an meinem Auto rum - gibt ja genügend Bücher für so etwas :rtfm:

TOP! Spart Geld und man lernt was!