Habe jetzt wieder einen mit über 20 MB und "Unban"
Dieser hat jetzt eine HighID aber Identification = invalid
Er bekommt auch keine Punkte.
Ich glaube das SNAFU gleich wieder zuschlägt.
Er ist nämlich schon wieder gebannt.
Alles innerhalb der Zeit, wo ich dieses Post geschrieben habe.

Ausserdem habe ich gesehen, wie dieser "Leecher" mit demselben
Hash und Namen mir DL gegegeben hat.
Doppelte Hash´s werden ja aus dem UL rausgeschmissen.

blomy,
so ganz sicher kannste aber dennoch nicht sein, daß es wirklich der Richtige ist. Einzige Möglichkeit wäre hier die IP zu checken, was aber so einfach leider nicht geht.

Bei einer Message sehe ich doch auch die IP.
Über RAdmin komme bei meinem Schwager auf den Rechner.
Er hat mir eine Message in Emule geschickt.
Ah ha - IP in Radmin eingetragen und eingeloggt.
Ansonsten muss er mir nämlich seine IP mitteilen.
Es geht also. Dann könnte man ja auch bei Details die IP anzeigen.

Hi bloomy,

Wenn ein Client wg. illegaler Funktionen gebannt wird, fliegt er aus der Queue
raus (ist eine org. eMule-Funktion, kein s.n.a.f.u.)

Bei Clients mit identification='invalid' kann man keinen 'unban' machen, die werden vom s.u.i. ertappt, und da greift der s.n.a.f.u. nicht mehr ein.

Ich sollte den 'unban'-Menüpunkt mal überarbeiten, das der nur noch dort steht, wo es auch Sinn macht..

cu
darkwolf

@ MxM. und @ Usul
Äaa... Leute...? Ne Frage so am Rande ,nicht falsch verstehen und bitte nicht böse sein aber das ist doch hier der Wombat Thread oder ?,ist zwar echt intressant eurer Thema aber könnte man das Gespräch nicht woanders zu Ende führen.
Hier zum Beispiel:
http://www.emule-web.de/board/emule-mod-development/
oder hier:
http://www.emule-web.de/board/board-kneipe-laberecke/

mfg
Odinasgardson

hoffentlich kommt bei den ganzen beirträgen auch was rum =)
Ich bin einer der würste die den ewombat fast mit standard settings laufen lässt, funktioniert aber ganz gut, achte nur darauf das die zuvielen verbindungen sich nahe null bewegen

Gestern hatte ich Gewitter hier. Brav und anständig, wie ich manchmal sein soll, habe ich meinen Rechner ausgemacht.
Tatsächlich hatte ich nen Stromausfall. Der FI ist geflogen! Man weiß ja was das ist, und was das tut!

Auf jedenfall habe ich nach dem Gewitter wieder alles angestellt.
Heute morgen war aber der Wombat aus. Vermutlich nochma Stromausfall.

Die Known.met war dann beschädigt. Soviel ich weiß, sind da die hashes der Dateien gespeichert. Ist da noch was drin und wie spielt sie rein?

cobrajet,
wenn Dir nur die known.met übern Jordan geht macht das rein gar nichts. Verlierst nur ein paar Statistiken und mußt einmal neu alle Deine Dateien hashen. Also nicht weiter schlimm.

MxM.,

da ja nun einige Irrtümer aufgeklärt sind, würde ich an dieser Stelle eine Schlußstrich unter die Diskussion ziehen, zumindest in diesem Thread. Wenn noch das Verlangen nach mehr Diskussion vorhanden ist, bitte sehr, ich beteilige mich gern daran, wenn es nicht zu diesem Thread passt, dann in jedem anderen.

Das mit Blacklotus ist wie von mir vermutet, es passt ihr nicht, das du so offen über Dinge redest, dir ihr privat (unter 4 Augen) besprochen habt. Ich sage das nur, weil ich als Moderator/Administrator hier auch eine gewisse Verantwortung anderen gegenüber habe. Normalerweise gehe ich davon aus, das Dinge, dich ich mit jemanden privat bespreche, nicht auf einmal irgendwo öffentlich in einem Forum zu finden sind, wenn ich es nicht ausdrücklich verbiete. Das hat was mit Privatsphäre zu tun. Ich weiß, das es Offtopic ist, sorry, aber es passte zum Anlaß. Ich will nur, das alles wissen, wenn sie mir dir irgend etwas per ICQ besprechen, das sie es dann unter umständen hier veröffentlicht finden. Ich persönlich finde das einfach nicht Ok. Bitte keine Diskussion dazu hier!

Odinasgardson,

sorry dafür, das es Offtopic wurde, aber der Anfang war Ontopic, es ging um die schlechte Uploadstatistik von eWombat. Das es dann ins Offtopic abdriftet, passiert dummerweise, ich wüßte aber selbst im nachhinein keinen Punkt, ab dem ich defenitiv sagen könnte, so, ab hier ists offtopic. Und übrigens, wer im Glashaus sitzt, sollte sich nicht nackt ausziehen (oder wie ging der Spruch? :mrgreen: ) Deine Wortduelle mit Sledge sind manchmal auch nicht gerade der Inbegriff von Ontopic ;-) Aber wenn wir uns alle gegenseitig kontrollieren, wirds schon werden. Kritik angenommen.

So, jetzt wieder Ontopic bitte, Thema ist eWombat

Sorry, das mich die Diskussion so mitgerissen hat ;-)

@ Usul, War ja auch nicht böse gemeint und das was ihr das geredet habt war ja auch intressant es war schon wichtig das das mal geklärt wurde ,das mit Sledge ist ne andere Sache.
Aber recht haste manchmal ist es arg OT. :oops:
Ich gelobe besserung oder ich kauf mir ne Strick und erschieß mich. :D
So das soll von mir hier das letzte mal Ot gewesen sein (hoffe ich )

mfg
Odinasgardson

ich frag mich gerade echt, inwiefern das hier gehandhabt wird.

nicht nur, dass ich ontopic war, bevor odinasgardson darauf hinwies, nicht nur, dass bereits diverse hinweise WIEDERHOLT zum offtopic NACH dem letzten OT meinerseits in meine Richtung abgesetzt wurden... nein, was mir letztendlich aufstößt ist, dass die Diskussion um OT mehr verschlingt als alles andere, letzten endes habt ihr nach euren eigenen hinweisen auf OT hier in aller öffentlichkeit weiter OT betrieben, ohne dass ich darauf eingegangen bin.

bezüglich blacklotus:

das war was ich schrieb.

und jetzt hab ich mir genauso mal gedanken gemacht wieviel usul hier jetzt um diesen satz herum an OT fabriziert hat... schlussendlich sogar blacklotus privat per icq kontaktiert... um eine diskussion zu führen...

möglicherweise ist jetzt mehr aufmerksamkeit auf der sache, als vorher gewesen war und alles nur, weil ich dieses mal nicht sparen wollte eine quelle zu nennen und warum man diese nicht einsehen kann. früher wurde kritisiert, dass ich einfach trübe aussagen treffe ohne hintergrund.

es ist doch falsch wie man es macht.

über öffentlichkeiten werde ich jetzt nicht diskutieren, aber ich hab mir erlaubt nach euren OT-eskapaden hierin selbst auch noch dazu zu greifen.

mit vorbild geht voran, wer fair veränderungen will. und forderungen kann nur stellen, wer selbst forderungen erfüllt.


schönen tag noch
max

Der Wombat läuft mir mir im Moment total schlecht. Ich bin jetzt erstmal wieder auf den LSD umgestiegen. Kann mir diese schlechten Stats nicht erklären :?:. Hab sonst nix laufen außerdem dem Wombat.

Ratio: 2.05 : 1 (2.90 : 1)
Downloaded Data (Session (Total)): 43.03 MB (66.81 MB)
Uploaded Data (Session (Total)): 88.02 MB (193.75 MB)
Average(5-min) DL-Rate: 4.76Kbs (12.90Kbs) UL-Rate 9.74Kbs (9.59Kbs)
\
Active Connections (estimate): 200 - Too many connections: 0
UL-Sessions successful: 35 - failed: 51 - Avg. time: 12:06 mins
DL-Sessions successful: 23 - failed: 26 - Avg. time: 10:32 mins
Waiting Uploads: 3722
Found Sources: 2967
SUI successful: 1436 - failed: 588
Detected 32 leechers, 2 credit thieveries, 0 friendshare-mod leechers
Detected 46 suspicious compressed blocks
Runtime: 2:36 h
Mem used: 73.46 mb free: 1974.41 mb

Über die Aussagekraft der UL/DL-Session-Statistik haben wir genug hier disktutiert, egal wie man dazu steht, ich geh mal nicht darauf ein. Es gibt andere ungewöhnliche Werte bei dir.

Diese Werte sind nach so kurzer Laufzeit eigentlich schon fast gut, bei mir siehts da manchmal schlechter aus..

Ist zwar nur eine Momentaufnahme, sieht aber auch Ok aus.

Klingt auch nach nicht übertriebenen Einstellungen.
Das ist total ungewöhnlich. So ein schlechtes Verhältnis hatte ich noch nie, hab auch noch nie bei jemanden ein so schlechtes Verhältnis gelesen. Beim LSD war dieses Verhältnis besser? Überprüf das mal, das ist der einzige wirklich auffällige Wert, den ich hier finde.

Vielleicht mal die zugehörige Funktion (Use Anti Zero Part File Handling) deaktivieren? Vielleicht sind es nur zu unrecht verdächtigte Blocks, kannst aber nur du selber beurteilen.

Nach 2,5 Stunden Kann man noch nichts sagen!

Nach 4 Stunden läuft er langsam ganz gut und nach 8 Stunden rennt er.

Theoretisch ja, aber die komische SUI-Statistik ist auch schon nach 2,5h auffällig. Die hat ja nichts mit der Laufzeit zu tun. Hier mal meine Statistik:

Ratio: 3,29 : 1 (1 : 2,12)
Heruntergeladen (Session (Total)): 16,50 MB (121,08 GB)
Hochgeladen (Session (Total)): 54,18 MB (57,19 GB)
Average(5-min) DL-Rate: 3,51Kbs (8,32Kbs) UL-Rate 11,54Kbs (12,35Kbs)
aktive Verbindungen (geschätzt): 68 - Zu viele Verbindungen: 0
UL-Sessions successful: 12 - failed: 10 - Avg. time: 16:11 mins
DL-Sessions successful: 2 - failed: 0 - Avg. time: 24:03 mins
Wartende Uploads: 743
Gefundene Quellen: 1599
SUI successful: 597 - failed: 0
Detected 11 leechers, 0 credit thieveries, 0 friendshare-mod leechers
Programm-Laufzeit: 1:33 h
Mem used: 71,78 mb free: 1976,09 mb


Schau dir mal meine SUI-Statistik nach nur 1:33h an, das ist ein himmelweiter Unterschied im Vergleich zu digitalfrost, und ich glaube nicht, das sich der Unterschied nach 8h Laufzeit ausgeglichen hat.

SUI failed bei mir nie?! Wobei ich maximal 10-15 Dateien im Download habe, seit SUI aktiv sein kann

987 : 1

das ist gerade der erste failed den ich je zu gesicht bekommen habe



darkwolf

wie kann ein failed SUI zustandekommen... ein als nicht SUI fähig erkannter client ist doch trotzdem kein failed SUI , oder ? also identifizierte leecher kann man nicht anhand dieser statistik lesen, oder ?

das würde mich auch interessieren wie kommt sowas zu stande hab auch max. eine failed

eMule v0.29c-LSD10b Statistics [digitalfrost]

Clients
Client Software
Port
Secure Ident (OK : Failed ): 2353 (24.18%) : 515 (5.29%)
Problematic: 0
Banned: 0
Filtered: 11

Nach 15:23 Minuten.

Bei mir gibt es failed SUI im Promille-Bereich, vielleicht 1-4 Stück bei 1500 erfolgreichen.

Korrektur, gerade nochmal nachgeschaut:

SUI successful: 2057 - failed: 33

es werden anscheinend mehr failed. Aber wo ist das Problem, das es sowas nicht geben dürfte? Wenn zwei Clients versuchen, sich gegenseitig zu identifizieren (also beide das Feature unterstützen), aber diese Autentifizierung aus welchen Gründen auch immer fehlschlägt (weil halt jemand sich für nen anderen ausgibt), dann ist SUI halt failed.

Das Verfahren funktioniert doch meines Wissens nach so: Bei der ersten Kontaktaufnahme werden die zur Identifikation notwendigen Daten ausgetauscht, beim nächsten Kontakt sind diese Daten auf beiden Seiten vorhanden und man kann überprüfen, ob der andere der gleiche ist wie bei der ersten Kontaktaufnahme. Theoretisch kann doch folgendes passieren: Ein Hashdieb meldet sich bei jemanden mit einem geklauten Hash zum ersten mal, die Daten werden ausgetauscht. Danach meldet sich der ursprüngliche Besitzer mit dem gleichen Userhash wie der Hashdieb, die Daten passen nicht mehr zusammen -> SUI failed. Geht natürlich genauso auch andersrum, wenn der rechtmäßige zuerst kommt und dann der Hashdiebe. Dummerweise kann man halt nicht überprüfen, ob beim Erstkontakt der richtige Nutzer den Userhash benutzt oder ob der geklaut ist.

digitalfrost,

selbst die LSD-Werte liegen total daneben, scheinbar liegt der Fehler bei dir nicht bei eWombat bzw. LSD bzw. überhaupt bei Emule, sondern woanders. Kann natürlich sein, das du selektiv zu bösen Buben verbindest, die gerade versuchen SUI zu knacken :mrgreen: , glaub ich aber eher nicht. Bei mir liegt das Verhältnis SUI success:failed bei 62:1, bei dir 4,6:1, das ist eine ganze Größenordnung mehr. Kann ich mir keinen Reim drauf machen.

Hi,

ein failed sui-Client kann nur zustande kommen, wenn der Client sui unterstüzt.

Für einen sui-client gibt es 3 verschiedene Werte:
id-needed: die puplic keys des sui-clients und des eWombats wurden ausgetauscht und der eWombat wartete darauf das das 'Sicherheitspacket' richtig verschlüsselt zurückkommt. Dieser Status erscheint nur kurz, sollte er sich nicht ändern hat der Client ein problem.
identified: Das Sicherheitspacket des sui-clients kamm richtig verschlüsselt zurück und der client ist o.k. (successful in der statistik)
id-failed: Das Sicherheitspacket kamm falsch verschlüsselt zurück, d.h. der sui-client benutzt ein ungültiges privat/public-key paar. Der client ist entweder ein Leecher oder der User hat sich einen neuen Userhash generieren lassen, aber vergessen die cryptkey.dat zu löschen oder umgekehrt.

@Usul:
Mittlerweile habe ich 'böse' Clients beobachtet die tatsächlich versuchen die sui-identifikation zu umgehen, dadurch können die failed-werte ziemlich hoch werden.

cu
darkwolf

frage ist ja nun, kann er nach einem failed zu einem download kommen ?

ich konnte nach diesem 1 failed (bei inzwischen 1075) nicht feststellen, dass jemand gebannt wurde, oder dass ein leecher detektet wurde.

Ich hab mal aus meinem Logfile die fehlgeschlagenen SUI-Vorgänge mit grep rausgefiltert:
Es sind 44 Einträge, genau wie der Wert in der Statistik für failed angibt. Wie man allerdings leicht sieht, sind es nicht 44 verschiedene Clients, sondern einige wenige versuchen es immer wieder. 44 ist anscheinend nur die Zahl der gescheiterten Versuche, aber nicht die Anzahl der Clients, die nicht identifiziert werden kann. Könnte man die Statistik nicht so bereinigen, das jeder Userhash, der nicht SUI bestanden hat, ein Fehlschlag ist und nicht jeder Versuch des Userhashs, sich zu identifizieren? Wenn ich das Logfile von Hand bereinige, bleibt nur soviel übrig:
Das sind nur 9 Einträge, ist doch schon besser als 44 ;-)

kurze frage, möchtest du dann "failed upload" auch so shrinken ? auf die useranzahl begrenzt bei denen der upload nicht zustandekommt.

ich denke der aufwand des berechnens durhc merken ist höher, als einfach diese zahl zu addieren. und die vorgänge sind ja nunmal die anzahl...weil wo gibt jetzt ein wert wieder, wenn dann die verbindung doch irgendwann mit einem von denen klappt...oder ob sie wirklich nie klappt.

MxM.,

ja, stimmt schon, zusammenrechnen wäre nicht gut bzw. zu aufwendig. Dummerweise ist es ja wohl so, das ein erfolgreicher SUI-Kontakt nur einmal zählt, ein fehlgeschlagener aber immer dann, wenn er fehlschlägt. Das Verhältnis success:failed bei SUI ist also etwas verzerrt, finde ich, man kann davon nicht auf die Anzahl der Clients schließen. Oder doch? Ist aber auch relativ unwichtig, vielleicht hab ich auch was falsch verstanden. Mir war bisher nur nicht bewußt, das die 44 Fehlschläge nur von 9 Clients verursacht werden (zumindest bei meinem Beispiel), vielleicht interessiert es ja auch jemand anderen.

Was das mit failed upload zu tun hat, ist mir nicht ganz klar :roll: .

ich vermute mal, dass ein und derselbe user auf verschiedene sessions auch mehrere SUI success vorgänge haben wird... , oder wenn er die verbindung zum server verliert, neu connected... dann dürfte er sich auch neu authentifizieren.

mit failed upload hat das jetzt nur die zahlen gemeinsam und meine frage an dich, ob das jetzt wirklich sinnvoll ist, alle werte auf die einzelnen nutzer runterzudividieren.

Natürlich ist es nicht sinnvoll, ALLE Werte auf einen einzelnen Nutzer runterzudividieren. Bei den SUI-Vorgängen hätte mich ein auf den Nutzer bereinigter Wert einfach interessiert, aber wie ich gesehen habe, kann ich mir den auch selber aus dem Logfile herausziehen. Besteht also von meiner Seite her kein Handlungsbedarf, da irgendwas an eWombat zu ändern.

Usul,
dank Dir für Deine SI Auskunft. Dachte bisher auch immer es wären 44 verschiedene User. Jetzt sind wir also mal ein ganzes Stück schlauer.

Ratio: 1 : 1,17 (1 : 2,14)
Heruntergeladen (Session (Total)): 1,09 GB (31,08 GB)
Hochgeladen (Session (Total)): 956,21 MB (14,53 GB)
Average(5-min) DL-Rate: 22,65Kbs (109,10Kbs) UL-Rate 19,35Kbs (27,25Kbs)
aktive Verbindungen (geschätzt): 627 - Zu viele Verbindungen: 0
erfolgreiche Upload-Sessions (total): 362
fehlgeschlagende Upload-Sessions (total): 82
durchschnittliche Upload-Dauer: 27:06 mins
Gefundene Quellen: 8974
Wartende Uploads: 5005
SUI Ok: 7251 Invalid: 56
Detected 348 leechers, 37 credit thieveries, 0 friendshare-mod leechers

Programm-Laufzeit: 14:04 h
Mem used: 170,31 mb free: 1877,57 mb

gvstarfleet,

interessante Statistik. Was hast du so für eine CPU-Auslastung bei eWombat? Fast 9000 Quellen verwalten, und das auf einem K6-2/450, nicht schlecht.

die ganze statistik is irgendwie der hammer.

für 14 stunden laufzeit erst recht

Hi,

Clients die den S.U.I. Status 'id needed' bzw. 'id failed' haben, bekommen keinen upload.

Gleicher Username bedeutet nicht zwangsläufig gleicher Client
Zwei Clients sind definitiv erst die selben wenn die IPs und die Ports gleich sind. Das sieht man recht gut bei den 'http://www.emule....' als
Nickname.

@Usul, das Problem mit der zählerei ist, das wenn ein Client neu in die Queue kommt, die S.U.I. Abfrage startet. War dieser vorher schon einmal in der Queue und hat sich abgemeldet, gilt er als neuer Client, und wird dementsprechend gezählt. Das gleiche gilt für Leecher etc. Ich könnte ohne Probleme eine Liste mitführen in der die gezählten gespeichert werden um nicht nochmal gezählt zu werden, aber diese Liste wächst dann mit der Laufzeit des eWombats (Speicherverbrauch, CPU Verbrauch beim durchgehen der Liste)

gvstarfleet, sind 627 aktive Verbindungen nicht einwenig viel? Ich denke, man sollte darauf achten, dass man mit den aktiven Verbindungen nicht über 100 oder maximal 150 kommt. Aber 627 (!!)... :?:

gvstarfleet, 627 - hört sich interessant an.
Bei mir würde bei dem Wert überhaupt nichts mehr gehen.

auch gefundene quellen sollten normal nicht so viel über 3000 sein.

am meißten download habe ich immer so bei 3200 quellen. da habe ich dann verhältnis 1:4

da ist der overhead zu groß, da kann kein anständiger download mehr gehen.

Nabend Leute,

muss leider mein leid klagen :(
eWombat 2x abgestürzt. Einmal gestern, einmal heute.
Gestern so ziemlich schlecht gelaufen. Ratio war mies, Connections bei den Files waren zu viele offen bzw. einige Files (gut verbreitet) hatten gar keine.
Hab dann in die log geschaut.

eMule.log:
23.07.2003 17:24:21: Unerwarteter Dateifehler beim Schreiben *.file : Unbekannt
23.07.2003 17:24:35: Unerwarteter Dateifehler beim Schreiben *.file : Unbekannt
23.07.2003 17:24:45: Unerwarteter Dateifehler beim Schreiben *.file : Unbekannt
23.07.2003 17:24:45: Unerwarteter Dateifehler beim Schreiben *.file : Unbekannt
23.07.2003 17:24:50: Unerwarteter Dateifehler beim Schreiben *.file : Unbekannt

snafu.log:
23.07.2003 17:21:25: Client:v5.1 - Mod:eMule v0.30 [DM-v5.1] banned by S.N.A.F.U.
23.07.2003 17:25:08: Client:PharaoEmu - Mod:eDonkey v60.0 banned by S.N.A.F.U.

5 verschiedene schon länger am ladende Files. Sofort nachgesehen ob Platte voll war oder kaputt aber nix von beidem. Wollte dann zurück zum Transfer aber da passierte schon nix mehr. Anscheinend in dem Moment abgestürzt.

Beim nächsten Starten natürlich Warnung...möglicherweise beschädigt, vollständig geladene Teile werden überprüft...aber alles noch da ... puh :D

Heute gut gelaufen aber dann einfach wech.

eMule.log:
24.07.2003 19:12:33: Heruntergeladener Teil 74 ist beschädigt :( <-- mehrere davon vorher und auch einen Server wechsel gehabt. Sonst nix auffälliges.

snafu.log:
24.07.2003 19:42:16: Client:Danke [RAMMSTEIN][emule.de][Leecha][3E][Filedeal - Mod:eDonkey v60.0 banned by S.N.A.F.U.
24.07.2003 19:42:30: Client:dqxmqe [eMule RAMMSTEIN v9] - Mod:eDonkey v60.0 banned by S.N.A.F.U.

Auffällt ist das das an beiden Tagen die snafu.logs mit einem Mod:eDonkey v60.0 banned by S.N.A.F.U. aufhört. Zufall?!

Ich muss dazu sagen das ich nicht neu angefangen habe. eWombat.ccf bei 3.31 MB also übernommen von der alten v062 und das ich die 17.7. Version drauf hatte. Einfach eWombat.exe ausgetauscht (nicht überschrieben) bzw. vorher schon in eMule.exe umbenannt.

Hm, hoffe hab alles wichtige drin un euch gut informiert.

Gruß Maddis :D

Hi,

@Maddis, hast du zwischendurch mal einen älteren Mod (z.b. LSD9) laufen lassen,
bzw. 'Use Anti Zero Part File Handling' aktiv ?

cu
darkwolf

@ darkwolf, Ich denke da Maddis, auch Betatester vom Lc Mod ist wird er wohl den zwischendurch am Start gehabt haben.
LSD ist natürlich auch möglich.
@ darkwolf, Wie siehts aus biste schon weitergekommen mit eWombat ?

greetings :lol:

mfg
Odinasgardson

Ov3rKiLL, blomy, cobrajet,

nicht übersehen, wie man am Upload von gvstarfleet sieht, hat er nicht ne normale DSL-Leitung, sondern was besseres (DSL 1500 vielleicht?). Die Erfahrungen mit Standart-DSL helfen da wohl nur begrenzt weiter (denke ich mal). Auf jeden Fall sieht der Download normal aus, auch die Uploadstatistik ist nicht schlecht (vom Uploaddurchschnitt mal abgesehen, aber das kann an tausend Dingen liegen).

selbst bei dsl 1500 sind fast 9000 quellen zu viel! Vielleicht bei 384 Kbit upload