Provider erlaubt eMule nur nachts von 18.00 bis 7.00 Uhr
 

Moin,moin, seit einiger Zeit laeuft bei mir P2P nur noch abends von 18 Uhr bis morgens um 7.00 Puenktlich um 7.00 Uhr morgens faellt der Hammer. Downloads sind sofort beendet und die Uploads sinken innert 1-2 Minuten ebenfalls auf 0. Es kommen dann noch ein paar Versuche einen Upload zu bekommen, aber es wird nichts mehr transferiert. Hab zuerst die Ports unter 1024 verschoben, nix. Also Ports 80 und 81, nada ! Punkt 7.00 ist Schluss. Ist nicht nur bei mir so, ist auch bei Freunden von mir, die zwangsweise beim selben Provider sind (hier gibts nur einen Provider) das gleiche Spiel. Das heisst also das der Provider Emule Datenpakete erkennen kann und sie irgendwie blockiert. Wie auch immer er das macht; ist mir egal. Tatsache ist, das er die Pakete indentifizieren kann, er sieht sie. Andere Aktivitaeten wie VNC remote Bedienungen, surfen, downloads von Webseiten, Skype, Notes Replikationen laufen ohne jegliche Behinderung. Wann also werden die Emule Pakete so verpackt/verschluesselt, das man sie nicht mehr als Emule Pakete erkennen kann oder wer kennt ein P2P System das dies schon leistet ? Ich versthe offen gesagt nicht wieso das bis heute immer noch kein Thema ist !!! Eine einfache Verschluesselung waere kaum eine Belastung fuer den Prozessor und der Aufwand fuer die Provider gewaltig, wenn sie alle Paketet durchtesten muessten. Also frage ich mal provozierend:Wo ist das Problem ? Gruss White Sand.


[edit by Pathfinder: Überschrift angepasst und verschoben von Xtreme MOD nach ISP]

...wow...von 1800 bis 0700...
...da bekommt der begriff flat-rate eine ganz neue bedeutung... :bang

...an eurer stelle würde ich mich mal mit dem isp in verbindung setzen...
...so eine drosselung ist schliesslich (sofern nicht in den agb`s verankert) nicht wirklich zulässig bei einer flat...

...oder...?! :think


greetz Sorrow :dance

Das Traffic-Verhalten lasse ich hier nur eingeschraenkt als Argument gelten, denn wenn an einem Internet-Zugang ein ganzes Buero mit 6 Leuten dran haengt, was macht der Provider dann ? Allerdings gebe ich zu das diese Buero nachts ueblicherweise wegfaellt. Deswegen eingeschraenkt gueltig. Also eine reine Drosselung kann es defintiv nicht sein, weil man waehrend Emule dahinsiecht, man locker mit Skype telefonieren kann und alle moeglichen anderen Dinge funtkionieren und dies mit ordentlich Datendurchsaetzen. Das heisst also nur die Emule-Kommunikation ist betroffen und das wiederum heisst der Provider kann die Pakete erkennen. Jetzt bliebe noch der Test offen, ob eventuell andere P2P auch davon betroffen sind oder nicht. Also zurueck zu meiner Frage: Was spricht gegen die Verschluesselung ?

Kann nicht einfach so sein, dass dein Provider Tagsüber zu berlastet ist?

Tja, leider sind wir nicht in Europa und der Provider ist absoluter Monopolist. Das Diskutieren ueber AGB's kann man da getrost vergessen: Er sitzt am laengeren Hebel.

Hi Luzifer, er ist defintiv tagsueber gut ausgelastet. Aber das erklaert nicht den selektiven Datendurchsatz und die Praezision (Punkt 7.00) mit der das Ganze sich ein- und wieder ausschaltet. Wegen der Auslastung wird er das wohl auch machen. Nur ist das natuerlich ziemlich willkuerlich denn ich zahle ja fuer die Uebermittlung von Daten ohne Ansehen von Geschlecht, Hautfarbe oder Religion, wenn ich mir diesen Ausdruck mal erlauben darf. Gruss, White Sand

Es ist auch ziemlich klare Politik von eMule, keine features zu bieten, die anti-ISP sind.

im Sticky auf der original-Seite steht unter "features You will never see in eMule" unter anderem encryption.

Nun wir nutzen hier zum Beispiel im Buero ADSL und . . . unser Domino Server laeuft auch nachts und dann wird sogar am meisten repliziert. Duerfte ein interessantes Profil sein.

Nun zunaechstmal danke fuer das freundliche rumeiern.
Wie ich eingangs schon schrieb habe ich diverse Ports bereits ausprobiert, auch Ports die sonst von anderen Programmen genutzt werden. Also bevor du hier auch rumeierst, lies mal vollstaendig was ich oben geschrieben habe. ;-)

Nun ich weiss zwar nicht was an einer Verschluesselung ISP-schaedlicher waere, aber da hier ja nun alle Paragraphen, aeh, Regeln schon festzuliegen scheinen, bin ich hier wohl an der falschen Stelle gelandet.

Meine Damen & Herren, bitte vielmals um Entschuldigung fuer die nicht regelkonforme Stoerung.

Aber eben kein P2P-Profil ;)

Hehe, wenn du also Ports ausprobierst die gleichzeitig von anderen Programmen genutzt werden, ist deine "Drosselung" selbst verursacht.
Wenn du Ports anderer Programme nutzt, die nicht gleichzeitig laufen, erkennt der Provider wieder das entsprechende Uploadverhalten und drosselt.
Das habe ich ja gerne, erst provozierend rumeiern (hihi) und dann dünnhäutig verabschieden :mrgreen:

Gruß, L3v3l

Wow, du willst offensichlich nicht verstehn.

Ich habe eindeutig geschrieben, das ich Ports benutzt habe, die sonst(!!!) von anderen Programmen benutzt werden.

Aber du hast recht, ich gebe auf, hier irgendwas diskutieren zu koennen oder weiterzukommen. Die Grundhaltung scheint mir hier reichlich kontraproduktiv zu sein.

Die deutsche Verwaltungs- und Beamten Gesellschaft scheint auch hier schon Einzug gehalten zu haben.

Schade drum.

White Sand

...im namen aller kollegen und kolleginnen dieser einrichtung sage ich herzlichst "Danke"...
...wir werden auch in weiterer zukunft alles erdenkliche tun, um sie im höchsten maße zufriedenzustellen...

...hochachtungsvoll Sorrow :whistle

Der Filesharing-Client Applejuice unterstützt standardmäßig verschlüsselte Übertragungen.

Das hat doch nichts mit Verschlüsselung zu tun. Viele Dateien im Netzwerk sind verschlüsselt, z.B. Sachen, die auf schrottesel.6x.to gepostet werden. Wetten, daß der Provider das trotzdem erkennt?
Wenn ich ständig zu völlig verschiedenen IPs Datenpakete von 9,3 mb schicke ist nicht schwer zu erraten, daß mir keine Schmuddelseiten im Netz ansehe sondern das Muli treibe...

Mit freundlichen Grüßen
aalerich

Unter verschlüsseltem Datenverkehr verstehe ich Traffic, der dem Provider keine Rückschlüsse auf die übertragenen Daten erlaubt. Dies ist nicht zu verwechseln mit anonymem Datenverkehr (Routing über mehrere Proxies/Zwischenstellen) oder dem Versenden von passwortgeschützten Archiven.
Die Chunkübertragung bei Applejuice erfolgt dynamisch. Meistens hat dort ein Chunk eine Grösse von ca. 500 KByte, jedoch kann es auch vorkommen, dass die Chunks eine Grösse von über 2 MB erreichen. Je grösser die Uploadbandbreite pro Slot des Clients, umso grösser werden die Chunks bei AJ.

Auf welcher Layer-Ebene die Verschlüsselung vom AJ-Traffic vorgenommen wird kann ich dir leider auch nicht sagen, jedoch glaube ich aufgrund der geringen Useranzahl im AJ-Netz und dem dafür notwendigen Aufwand nicht daran, dass das AJ-Protokoll bereits durch jemanden entschlüsselt worden ist, bzw. das der Provider den entstehenden Traffic dem AJ-Netz zuordnen kann.
Der Thread-Autor sollte es einfach mal ausprobieren, ob es mit AJ klappt oder ob der Provider anhand der Traffic-Charakteristika erkennen kann, ob es sich tatsächlich um P2P-Traffic handelt und ob er diesen Traffic ebenso wie bei Emule behandelt. Einige Router, z. B. vom Hersteller Draytek, können bereits unterscheiden, ob es sich um Traffic aus den Tauschbörsen BitTorrent, Edonkey, Gnutella oder Fasttrack handelt und diesen ggf. blockieren. Eine Einstellungsmöglichkeit AJ-Traffic zu blockieren gibt es bei den Routern von Draytek noch nicht.

Auch wenn sich dieses Thema scheinbar bereits erledigt hat da die letzte Antwort schon etwas her ist - Port 82 wäre ein Versuch wert.
Ich war mal bei einem Anbieter (Faventia) der hat massiv gedrosselt, kein P2P möglich. Also mal Ports ausprobiert und mit 82 lief alles wunderbar, den werden wohl auchdie wenigsten Anbieter fest sperren, es sei denn es werden Ports je nach Nutzverhalten gedrosselt. Aber dazu gibt es ja die Möglichkeit des "Port Random" bei zahlreichen Versionen.

:yes: Schade, daß der Thread schon älter ist,

würde mich ja interessieren, ob in Fällen wie diesem hier die Protokollverschleierung der neuen eMule Versionen Wirkung zeigt. Daß ISP mit Bandbreitenmanagement / Traffic Shaping zu Stoßzeiten HTTP bevorzugt weiterleiten und andere Protokolle zum Teil massiv mit busy Signalen bombardieren ist ja bekannt. Nur, ob ein eMule Protokoll abgewürgt wird, daß nicht die übliche Struktur hat und ob das obfuskierte Protokoll nach kurzer Zeit wieder als solches erkannt wird ???

greetz

... Cat ... ;)

White Sand? Noch am Ball. Esel Metaller? DER Eselmetaller aus dem Chip Forum?

Es laeuft wieder.
 

Hallo Clondike Cat,

danke fuer den Hinweis. Habe danach die neue Version gestartet und ... in der Tat ... es laeuft wieder einwandfrei, nur Kad , keine Server. Aber ich habe auch Ants installiert, denn ich denke es ist nur eine Frage der Zeit bis Cisco & co. wieder was ausgetueftelt haben und dann dreht sich das Karussel wieder. Das wird solange gehen bis ein Ants aehnlicher Zustand erreicht wird. Wage mal diese Vorhersage. ;-)

Hi Katze :beer:

Ja, ich war in Zeiten der grossen Langeweile auch öfters mal im Chip Forum unterwegs :whistle
Ich denke wir sollten uns mal unterhalten, denn das Thema hier interessiert mich auch sehr.

Aus Brasilien, wo das Muli wohl so ziemlich flächendeckend blockiert wird, kommen Meldungen, daß die Verschleierung hilft. In Italien muß es wohl ähnlich sein; seit der Verschleierung habe ich mit Italienern die selben Probleme wie schon immer mit Spaniern, was ich so deute, daß viele Italiener, die früher kein Muli laufen lassen konnten, es jetzt tun und das bis zum Anschlag. Aus Deutschland hab' ich noch nichts gehört, insbesondere KabelBW würde mich auch mal interessieren. Einen ganz indirekten Hinweis, daß es auch da hilft, habe ich, aber halt keine klare Aussage. White Sand, wie schaut's aus bei Dir, KabelBW?

Neugierig grüßend
aalerich

also ich habe gestern zum test in ka den xtreme über kabelbw laufen lassen. lief ohne probs....

Jep, dacht' ich's mir doch, danke für die Info!

Mit freundlichen Grüßen
aalerich

KabelBW
 

Hi zusammen,
hab mal ne Frage bezüglich KabelBW.

Hab Anfang der Woche von T- DSL 1000 auf Kabel6000 umstellen lassen.
Funktioniert alles prima, auch alle Speedtest sagen ich hätte ne "volle Pulle Leitung".
Der Muli allerdings kommt mir total eingegrenzt vor.
Hab den Upload auf62 begrenzt <- funzt wunderbar, alles ruhig und sauber
Der Download ist auf 500 als max. gestellt, jedoch war mein bester Wert diese Woche mal für ein paar Minuten bei 100.
Wenn ich rein kucke hab ich eigentlich immer zwischen 40 und 60.
Das halt ich für extrem wenig bei ner 6000er Leitung, zumal ich im Gesamtvolumen mit meiner 1000er DSL Leitung genauso schnell war.
Sauge momentan ca. 13 Files gleichzeitig, alle!!! super verfügbar. Also keine seltenen Dateien.
Jetzt hab ich mir sagen lassen dass die Möglichkeit besteht dass ich von KabelBw eingegrenzt werde.
Kann mir da jemand nen Tipp geben wie ich das ganze umgehen kann. Gibts ne Muli Einstellung die mich wieder auf verfünftige Up - Down Raten bringt?Momentane Ul DL Ratio liegt bei 1,14 : 1!!!!! Das geht gar nicht klar....

Dank euch schon mal für die Hilfe!
Greatz Maker

http://img177.imageshack.us/img177/6505/spinnersg7.png

Soviel dazu...

Mit freundlichen Grüßen
aalerich

Aalerich, du bist ja ein schatz für das filesharing!...
...aber mal spass bei seite: GEDULD!...
...mein muli läuft jetzt seit ca. 24 stunden, und ich habe 1:1.3 ....wer gebet der nehmet....(oder so ähnlich...)

mfg
myth88

:yes: Hallo maker,

hab leider nur einen etwas älterem Bericht gefunden:

Onlinekosten.de - News - Kabel BW: König Kabel neuerdings Anti-Filesharing?

Kurz zusammengefaßt, ja, zumindest ein Teil des Netzwerks von Kabel BW benutzt ein Bandbreitenmanagement. Erfahrungen mit Tiscali (1000'er Anschluß damals) - Symptome:

Trotz moderater Einstellungen verliert eMule die Serververbindung und verweigert die Verbindung, vor allem mit Servern, die den Standardport 4661 nutzen, aber auch 4242 läuft schlecht. 3000'er Ports werden genommen. Auf Standardports saugt das Mulie schlecht, auf 3000' er Ports geht es kaum über 25. Man sieht manchmal, wie die Übertragung von Quellen aus anderen, vor allem ausländischen Netzen kurz nach dem Verbindungsaufbau abgewürgt wird. Meinen Verdacht, daß das Zeitabhängig eigenartige eMuleverhalten tatsächlich vom Telefonica / Mediaways Backbone gesteuert war, war schnell bestätigt, nachdem ich meine neue Flat im T-Com Backbone schon nutzte, obwohl die Tiscali Flat noch aktiv war. Ein Providerwechsel, mit einem Mulie, der gerade noch, trotz guter Quellen, nicht in die Hufe kam und das Maultier verdoppelte mal eben seinen Download. Spitzenwerte von etwa 60 kByte/sec. wo eine halbe Stunde vorher, immer wenn es gerade mal auf 30 ging ein Zurückfallen auf 25 zu Beobachten war.

Mit wehendem Maultierschweif zurück zu Tiscali und ... Server, die gerade Problemlos zu kontakten waren ... voll. Download? Tröpfel!

Der neue Mulie wird sicher erstmal, wenn du die Protokoll Obfuskation einschaltest besser arbeiten, aber nicht perfekt, denn dort, wo es der Backbonebetreiber nötig hat, Bandbreitenmanagement einzusetzen, werden in Stoßzeiten Protokolle für VoIp und HTTP bevorzugt behandelt, dann kommt FTP, ICQ, IRC und unbekannte Protokolle, wie eMule verschleiert, werden vielleicht nicht extra gebremst, aber bekommen solange busy Signale draufgepappt, bis die priorisierten Protokolle wieder genügend Bandbreite übriglassen.

Das sind völlig normale Werte. Mit einem "normalen" eMule wirst du nur dann höhere Werte hinbekommen, wenn du dir bei den Mulies, die haben, was du suchst, schon Punkte erwirtschaftet hast, oder wenn du einen frischen Release zum richtigen Zeitpunkt ziehst, nämlich dann, wenn die Release Crew gerade angefangen hat zu pumpen und noch kaum Sauger unterwegs sind.

Im Schnitt wirst du nur einen geringfügig höheren Download erhalten, mit der dickeren Leitung, außer du saugst rares Material und hälst dabei deinen share sauber. Dann macht es sich natürlich bemerkbar, wenn du die Mitbewerber schnell mit den Brocken belieferst, die du schon hast. Die 100 % Quellen müssen dann nur noch nachliefern, was die Sauger als Gesamtheit nicht haben.

greetz

... Cat ... :)

Servus Cat, danke erst mal für den Bericht.
Hatte vergessen zu erwähnen dass ich schon nen gemoddeten Muli nutze, keinen Standard Emule.
Nutze die Version Morph XT 9.2.
Bin schon seit mehreren Jahren auf dem Morph Mod hängen geblieben. Würd also behaupten dass ich schon etliche Credits gesammelt habe:dance:dance

So wie ich in anderen Foren gelesen habe soll der Morph ja auch angeblich der beste für KabelBW sein, passt dann ja...
Kanns mir nur echt net erklären, n kumpel von mir nutzt auch ab und an Emule. Er hat auch KabelBw und hat ne Geschwindigkeit beim saugen dass die Wände wackeln.
Irgendwas stimmt einfach net. Hab dem Muli heut Morgen mal 2 neue Ports zugewiesen, aber bisher hab ich keine Veränderung zu vorher festgestellt.....

:yes: Hmm, ich verweise mal auf den Thread hier:

http://www.emule-web.de/board/8469-f...kabelbw-7.html

sieht danach aus, als ob zumindest Teile des Netzes von Kabel BW mehr Kunden haben, als sie verkraften. Wenn das, was drfreak da schreibt auf deinen Einwahlknoten zutrifft, dann sind Hopfen und Malz verloren, weil ein Netz, was ständig überlastet ist, braucht kein Bandbreitenmanagement mehr, um den Mulie zu versteinern und kann auch mit Bandbreitenmanagement den schnellen Aufbau von Webseiten, sowie zügige Downloads von FTP Servern nicht mehr sicherstellen.

Lange war es üblich, daß Provider mit eigenem Backbone HTTP priorisiert, später eMule und Kazaa zusätzlich gedrosselt haben, um, trotz geringerer Leistungsfähigkeit als T-Com, die Kunden zufriedenstellen zu können, bis genug Geld für einen Ausbau da war. Ohne Ausbau ist es schlicht Betrug vielen Kunden große Bandbreiten für teures Geld zu verkaufen.

Check mal, ob du in dein Postfach, ins gmx Media Center, oder zu einem One Click Hoster eine größere Datei mit der Geschwindigkeit hochladen kannst, die dein Anschluß hergeben soll. Für den Test des Downstreams vielleicht mal 'ne Nero Version vom Nero Server ziehen. Wenn nicht gerade eine frische Version da ist, die sich viele Leute gleichzeitig ziehen, liefert der sehr gut.

Wenn nur das Mulie & Co gebremst wird und daß in den Vertragsbedingungen festgehalten ist, kannst du nichts machen, aber wenn generell alle Up und Downloads spätestens dann lahmen, wenn das Gegenüber in einem anderen Netz zuhause ist, gibt es Grund zur Reklamation, Fristsetzung, außerordentlicher Kündigung, wenn der Mangel dann nicht beseitigt wird. Und dann ab zur T-Com / T-Com Reseller, wenn die wenigstens 'nen 6000'er light schalten können. (3072 kbit/sec. down / 384 kbit/sec. up) Dat iss dann zwar net soo viel, aber dat iss stabil.

greetz

... Cat ... ;)