Client sendet nichts...!

[amax]

Bei dem connect Problem mit dem Server ist folgendes aufgetreten.
Er läuft bei uns weder unter 98se
noch XP SP1.

Es scheint am Client zu liegen!
Wenn wir auf schon bestehende Server gehen wird von Client empfangen und gesendet.

Wollen wir aber auf unsere neu aufgesetzten Server, so empfängt der Client genau >>>208 bytes!!! >>>vom server.
Er selber sende nichts und die ports gehen auf der clientseite sofort wieder zu!!!
Wir hatten immer den Server im Verdacht
aber dort taucht die Client -IP ja auf.
Die ports bleiben offen.
Nicht so auf der Clientseite.Sofort nach dem connect Befehl gehen die ports auf
und sofort wieder zu und einen Moment später kommt dann der Text , das der server wohl down ist oder TS nicht läuft.

Scheint etwas buggy zu sein ......

aMax

[Dummer Sack]

Es kann auch sein das die vom Server ausgehenden Pakete geblockt werden.
In diesem fall sendet der Server zwar aber der Client bekommt keine Antwort und macht die Verbindung wieder zu.

Das kann an einer fehlerhaften Firewall Regel liegen oder an fehlerhaft implementiertem NAT am Router (Falls auf Server oder Client seite verwendet wird) oder fehlerhaften Forwarding Regeln oder machmal macht sogar der ISP ärger.
Falls ein Router verwendet wird der Packet logging hat könnte man dort überprüfen ob die Pakete vom Router gesendet (Server Seite) oder empfangen (Client Seite) wurden.

Falls keine Router verwendet werden kann man sich die Pakete mit Ethereal (http://www.ethereal.com/) ansehen. Bitte beachten: Ethereal funtioniert nicht über einen Switch.
Also nur über einen HUB oder direkt am zu beobachtenden Rechner verwenden.

[amax]

@Dummer Sack
Also werde mal nägel mit Köpfen machen.

Firewall funktinioniert, aber haben ihn zur Vorsicht deaktiviert und nicht beendet
,da die Speicher residenten Teile ja noch bis zum reboot arbeiten.

Ich benutze "OUTPOST" und da sieht mal schön was auf den Ports los ist.
Gegebenenfalls überprüft man einfach die Regel.

Was der Router macht kann ich nicht 100% sagen. I
Ich habe es nur von PC1>PC2 über DSL probiert (beide aber hinter dem Router) und es ging , über Weblist und Quick.
Von PC1>PC2 über analog Modem gehst nicht. Das heist die aktuelle IP des Analog ISP taucht auf der DSL
Leitung auf. Aber der Client sagt "no Connect"

Kann es sein das bedingt durch die Bandbreite des V90 Modems der Client > TS blockt?

Werde mal Etheral auf beiden Rechner starten und sehen was der Router durch läßt.
Ich kann das leider nur wieder lokal ,da man auf der anderen Seite kompetente
Leute mit Etheral haben muß, und die sind rar.l

Er müsste aber 100% gehen ,ich habe zudem die IPs auf den Rechner fest und im Router fest an die MAC gebunden.
Und Port forwarding ging bisher mit JEDEM dussligen Programm und warum sollte es nun gerade bei 8767 UDP nicht gehen. Das schließ ich aus.
BTW als DMZ host und zurückgenommen Portforwarding geht es auch nicht.....??

aMax

[Dummer Sack]

PC1>PC2 über DSL bedeuted das die getrennte DSL Verbindungen haben (Also getrennte Gateways?)
Oder bedeuted das, das beide einfach über den Router gehen, aber halt über die externe IP. Wenn das tut hast du Glück gehabt. Die meisten Router unterstützen das nämlich nicht.
Das ganze ist aber im endeffekt nur wieder eine lokale Verbindung. Kein Paket geht babei über den ISP. Allerdings immerhin schon mal durch das NAT vom Router.

Die Frage ist, wenn du über das Modem verbindest: Kommen die Pakete die der Server sendet auch am Client Rechner an?
Das sie gesedet werden kannst du ja anscheinend verifizieren. Versuch das gleiche halt mal am Client mit den ankommenden Paketen.
Wenn die Pakte nicht ankommen blockt der Router, der ISP, oder eine Firewall auf dem Rechner mit dem Modem die Pakete.

[amax]

Nein sie gehen beide über den selben Router und auch nach draußen.
Ich habe beide mit Etheral gesnifft und
man sieht eindeutig die Anfrage an den DNS .
Die daten gehen vom protokolhandshake nach draussen wie es physikalisch ist...no idea.

Aufgefallen ist mir nur das Verhalten des Clients . Kaum gestartet ( ohne connect zum TS server), gehts gleich nach
abuse.teamspeak.org und weblist.teamspeak.org.
Danns steht da noch was von encryptet data und das wars. Er verbindet sich mit dem Server.
Nur wenn ich das auf dem selben Rechner einen Moment später über das DFÜ gate ,also zwei verschiedene gateways starte,gehts nicht.
Ich habe fast den Eindruck , als wenn er von TS.org nicht die genehmigung erhält.
Denn auf bestehenden servern geht das teil einwandfrei.

Ich sniffe noch mal beim externen connect. Hoffendlich kann mein Kumpel damit umgehen. Du weist ja , installieren können sie alles......

aMax

[amax]

Nachtrag:
Mit Etheral auf auf serverseite eth0 und
auf clientseite pppmac (56kModem) gesnifft.
adressen Ok ports OK >>> Verbindung keine.
Ich denke mal der Server ist geblockt.
Quote:
"In case of breaching the terms of this license "Dominating Bytes Design" reserves the right to block any traffic to the
users "Software Program"

Das wird es wohl sein.... .-(

Scheint etwas schiefgelaufen zu sein.

Frage : Neustalation ? Neuer Name?

Oder wird über hash gearbeitet. und es ist auf diesem Rechener zwecklos.?

aMax

[Dummer Sack]

Originally posted by amax
Nachtrag:
Mit Etheral auf auf serverseite eth0 und
auf clientseite pppmac (56kModem) gesnifft.
adressen Ok ports OK >>> Verbindung keine.Heist das jetzt, dass JEDES Paket was am Server gesendet wurde auch beim Client angekommen ist?
Und der Client dann trozdem dem Login vorgang abgebrochen hat?
So weit ich wiess kann man bei Ethereal die Protokolle auch speichern. Evtl. kannst du das ja mal am Client und Server machen und die hier irgendwie zum Dowload zur verfügung stellen.
Originally posted by amax
Ich denke mal der Server ist geblockt.
Wenn der server beblockt ist bekommst du im Client die meldung "Server is Blacklisted". Wenn du die nicht bekommst ist er auch nicht geblockt.
Wenn der Derver Blacklisted ist wird so weit ich weiss nicht mal ein Login eingeleitet.

[amax]

Nein dazu kommt es nicht.
Vom server ist nichts angekommen. Keine Fehlermeldungen im serverlog! Die IP vom Modemhost taucht auf der Serverseite auf.

Modem(client)> Compuserve(AOL)
dieser PC wurde komplett vom Netz genommen( Kabel ab/kein Tcp/ip für die Netcard.

DSL über Router (server) > QSC

Der Client fragt nach der IP des Servers über DNS nach und dann taucht seine IP
auf der Serverseite auf. Danach ist der Client nur noch mit abuse.teamspeak.org
beschäftigt und es geht nicht weiter.
Im Clientlog steht dann das Login phase 2
nicht gekommen ist.
Damit das portforwarding nicht fehlschlägt,
warum sollte es ,es ging bisher mit jedem
Programm, hab ich es dann abgeschaltet und den ServerPC sogar als DMZhost an meine externe
IP gebunden! In ini file hab ich das bindtoip freigelassen.
Und ........null.
Mehr kann ich nicht mehr machen.auf den Router kann ich nicht verzichten

Sonst geht die Software als Müll in die Tonne.
aMax

BTW Bei Interesse kann ich die Logfiles + snifferdatein mal schicken( Server+client)

[Dummer Sack]

Also wenn ich dich recht verstehe passiert folgends:

Client sendet zum Server.
Paket kommt beim Server an.
Server sendet zum Client.
Beim Client kommt nix an.
Client bricht Login Vorgang ab.

Das heist für mich das das Paket vom Server irgendwo zwichen Server und Client abgefangen wird.

Auf dem weg zwichen Server und Client liegen: Der Router, QSC, AOL, Client PC mit modem.
Ich denke mal nicht das es an QSC liegt. Das hab ich auch und bei mit tut der Server ohne Probleme.
Bleibt noch: Der Router, AOL, der Client PC.
Da das Problem ja anscheinend auch bei anderen auftritt, die nicht über AOL gehen und auch andere Client PCs haben, fällt auch AOL und Client PC weg.
Es sei denn es gibt irgentwelche Gemeinsamkeiten zwichen deinem und deren Client PC die für das Problem verantwortlich sein könnten.

Also bleibt noch der Router übrig.
Entweder is irgendwas in der Konfiguration nicht korrekt oder die Firmware ist Buggy.

[amax]

Die Konfiguration ist korrekt.

Du kannst entweder den Port forwarden
oder den host in die DMZ stellen .Korrekt?
Mehr ist nicht zu tun und mehr wird nicht im Manual verlangt.
Der Router hat bisher mit allen anderen
Programmen und deren ports funktioniert.
Warum sollte er ausgerechnet beim UDP 8567 oder wie bei mir 8500 nicht gehen?

Das ist sehr unwahrscheinlich.

Kommen wir mal zur Sache.Bisher hat niemand etwas über die Prozedur des Connects gesagt.Wie der abläuft und was die TS.org portsdamit zutun haben.
Ohne Flussdiagram ist das eher eine Diskussion für Newbies .
Wonach und zu welchem Zeitpunkt soll man was suchen?

Immer auf der Routerkonfig zu reiten ist arm.Das sollte mindestens nach dem 2 Post gelaufen sein.Ich habe schon etliche Stunden damit zugebracht verschiedene Konfigurationen durchzuspielen.Ich bin aber kein Beta Tester, die haben etwas mehr als dieses armselige servermanual.

Nimms nicht persöhnlich , aber etwas mehr Information ist schon notwendig.

Amax

[Dummer Sack]

So etwas wie ein Flussdiagramm gibt es nicht. Das genaue Protokoll kennen nur die Developer und die haben sich so weit ich weiss noch nicht dazu geäussert.

Allerdings ist es klar das bei dir etwas anderes nicht stimmt, wenn ein Paket vom Server gesent wird und nicht beim Client ankommt. Da hilft dir auch keine genaue kenntnis des Protokolls weiter.
Viele Router haben zusäzlich noch Packet Filter und andere spielereien.
Möglicherweise hast du ja davon was an.
Oder deine Firmware ist möglicherweise buggy.
Schau doch mal in ein Router Forum ob es bekannte Probleme mit deinem Router und einer bestimmten Firmware Version gibt.

Falls Englisch ok ist, ist hier (http://www.broadbandreports.com/forums/18) ein ganz gutes.

[amax]

@Dummer Sack

Zu meine Router:

Er unterstützt eine "externe IP" in lokalenetz.!!!!

Test>
Server PC1 (192.168.6.4)port 8500
Router : portforwarding port 8500 auf 192.168.6.4
PC2 (192.168.6.2) Quickconnect+Webconnect+Phone geht über EXTERNE IP.

Nun portforwarding AUS

Mit EXTERNER IP kein connect mehr möglich.

Jetz nur noch auf Interner 192.168.6.4:8500
Portforwarding wieder ein> geht wieder!
Also geht es zum ISP und kommt wieder zurück.

Packet Filter+ Packetforwarding ist nicht gesetzt

Sowie es aussieht müsste alles funktionieren.
Aber wie die tests gestern gezeigt haben.Ist es mit einem Modem(V90) nicht möglich sich einzuloggen
Es ist oder wird ein Rätzel bleiben....oder ?


amax

[amax]

Add:

ServerPC
Es sind folgende ports da:


Local 1029 UDP > remote 45647:abuse.teamspeak.org >OUT

Local 51234 TCP remote *.*.*.* Listening

Local 1453 TCP remote *.*.*.* Listening

Local 8500 UDP remote 1365: QSC(meine externe IP) <Client <IN

amax

[Dummer Sack]

Ausschliessen kann man es natuerlich nicht, das es am Protokoll liegt.

Aber dann eher wegen zu kurzer Timeouts beim Login Prozess und nicht weden dem abuse.teamspeak.org kram.

Ob die Timeouts zu kurtz sind für Modem Verbindungen müssen die Entwickler überprüfen. Dazu kann ich hier nichts sagen.

[amax]

ADD:

Der "abuse kram" ist aber bestimmt jede 2-3 Anfage auf der clientseite...
;-)
Wie sieht das mit den Serverversionen aus?

Mein server.EXE hat die Version :2.0.19.484

....484????
Ist das aktuell?

Im englischen Teil hat gerade jemand etwas von der Unverträglichkeit des Servers mit dem neuen client 2.0.32.60 gepostet.....??

Ich bin scheinbar nicht der einzige.

Gruß aMax
...und erst mal vielen Dank für die Mühe.
Der thread ist lang geworden.
Ich muß wohl auf ein neues release warten.

[Dummer Sack]

Es gibt wohl einige leute die probleme haben mit dem 2.0.32.60 client zu verbinden. Die tritt aber sowohl mit dem 2.0.19.40 als auch mit dem .46 server auf.
Mit dem .46 server wohl sogar eher weniger.

Möglicherwiese wurde beim 2.0.32.60 Client irgendwas im Protokoll geändert (timeouts verkürtzt, order sonst irgend was), das dieses Problem hervorruft.

Einigen hat es gehlofen den .57 Client aus dem Developer Releases Forum zu nehemn. Aber ich glaube das hast du schon probiert.

Die aktuelle Server Version ist 2.0.19.40.
Das aktuelle Developer Release ist 2.0.19.46.
Die Versionsnummer die in der server.log ausgegeben wird ist die richtige.

Und ja, du bist nicht der einzige. Das Problem hat aber bei verschieden Leuten verschiedene Ursachen so das eine einfache Beseitigung des Problems bisher nicht gefunden werden konnte.