![]() |
Häufiges "received an IP: **** NAFC-Adapter will be checked Diese Meldung kommt manchmal alle paar Minuten mit immer derselben IP und erzeugt dann auch einen PopUp. Sollte dies bei identischer IP nicht unterdrückt werden ?? (Xtreme 5.4) |
Erklärung siehe hier: http://www.emule-web.de/board/11138-...+IP#post109201 Beseitigung: - Upload korrekt einstellen (empfohlen) - oder: in der preferences.ini in der Xtreme-sektion den Wert internetdownreactiontime=2 die 2 auf einen höheren Wert setzen (z.b. 5) (bis 10 ist möglich) |
Zitat:
Ich 'meine' den Upload korrekt eingestellt zu haben, aber i.d.R. sehe ich nur 50%, vermutlich weil die ausländischen Clients einfach nicht besser abnehmen?? In der INI war kein Eintrag auszumachen, gilt dann der Default 2? |
Zitat:
Zitat:
Zitat:
|
Immer noch :( Mit dem Eintrag in der ini auf 10 gestellt wird die Meldung viel seltener, d.h. noch so durchschnittlich 1/h. Warum denn im Code kein Vergleich ob sich die IP tatsächlich geändert hat? |
nachdem Du inzwischen ja selbst schon einfrig im Code unterwegs bist, überlaß ich es Dir mal selbst auf die Frage zu antworten. |
Mhm - die 5.4 macht das nicht. Die 5.4.1 mit gleichen Parametern und fast identischen Sourcen meldet sich halt eben mit "NAFC ....." Oder die Telekomiker fummeln mal wieder am Netz herum.(Das ist blöd) Oder ich soll mal wieder ein Schwätzchen mit Xman halten. Das ist eine gute Idee ! |
5.4 -> 5.4.1 nix geändert an diesen Dingen. |
Dann tendiere ich eindeutig 1.) die Telekomiker haben in der Zeit gefummelt als die 5.4.1 lief und 2.) was mir besser gefällt : ein nettes freundliches Schwätzchen mit dir zu halten. Ich versuche dann Kaffee & Kuchen mit einem kleinem Verdauungsschnaps zu organisieren. |
aber vieleicht hast Du auch mal den Wert für internetdownreactiontime auf 1 gesetzt .. das schrieb ich Dir nämlich mal inner PM. Und 1 bedeutet eben: fließt 1 Sekunde kein Upload, dann überprüfe die IP. |
Zitat:
|
mensch..ich hab Dir doch die Antwort indirekt in meinem letzten Post gegeben. -> Die Meldung bedeutet, daß ein Vergleich gemacht wurde. |
Zitat:
|
Zitat:
|
Zitat:
wird dir mein Dank gewiss sein. Das war es aber nicht. Igendwas läuft total schief. UL und auch der DL bricht ein. Im Statistikfenster ist bei allen 3 Verbindungslinien ein sehr heftiges auf und ab zu sehen. Die aktiven Verbindungen gehen auf den Begrenzerwert von 250 und wieder zurück auf etwa 180. Das passiert so in etwa alle 20 Min. meistens in kürzeren Abständen.. Wenn die aktiven Verb. nach oben gehen, marschiert der UL und auch der DL nach unten. UL manchmal bis auf 0. DL bricht bis auf 15 zusammen. Dann sind es auch zuviele Verbindungen. Im UL-Fenster liegt der zweite Wert so um die 95 bis auch 100. Selbst Clienten, wo ich weiss, das sie ohne Problem abnehmen, werden störisch. (Jetzt ist ein Client im UL & DL bei der 5.3 ohne irgendein Problem, vorher war er störisch) Found Sources 6531. Waitings Clients 5128. Das sind Werte, den die Xtreme-Mods immer ohne Probleme verarbeiten haben können. Vor allen Dingen gibt es keinen Grund für dieses Verhalten.Jedenfalls nicht in diesem Takt. Router arbeitet problemlos. I-Net wird anstandslos aufgebaut. DL`s gehen ohne Probs. Router ist ein AVM FritzBox 5050 - also kein Billig-Teilchen. Jetzt hab ich mal die 5.3 angeworfen. Wenn die auch son komisches Verhalten an den Tag legt, muss ich mal schauen, was mit meiner Leitung los ist. Scheibenkleister, wo ich doch den 1 Release UL-Slot und auch die UL Automatik ins Herz geschlossen habe. Jetzt funktionieren die Rechner und ich meinte, ich könnte mich mal um andere Dinge kümmern als diese Möhrchen am Laufen zu halten - neee, es soll nicht sein. Tja - wie soll es anders sein. Die 5.3 zeigt ein ähnliches Verhalten. Resumee : Eselrechner und Konfiguration überprüfen. Ach - ich bin ja so happy. Hat einer mal nen grossen Stein für mich ? Einfach mal reinschmeissen. |
hätte mich auch sehr gewundert, wenn die 5.4.1 ein anderes Uploadverhalten an den Tag legt. Beim Upload (zumindest im Core-Code) hab ich schon lang nix mehr gemacht. Aber damit begründet sich auch das Thema des Threads, bzw. diese Meldung. Auch wenn internetdownreactiontime=1 steht darf diese nicht kommen.. nicht bei Deinem hohen Upload. Selbst wenn Du nur 40 kb/s rausjagst dann überleg Dir mal wie oft in der Sekunde ein Packet mit MTU-Größe rausgehen muß. Eine ganze Sekunde ohne Upload ist da ziemlich unwahrscheinlich. |
Tja und der UL ist auf 0 gegangen. Genau das hat mich ja stutzig gemacht. Ich hab mal den Eselrechner und auch die Fritzbox vom Strom getrennt und wieder gestartet. Beide sind seit dem 6. Januar im Dauerbetrieb. Jetzt muss ich noch ca. 20 Min. warten, ehe ich Ergebnisse sehe. Ich denke aber, das beide Teilchen irgendwie wuschelig waren. 5.4.1 is running. Na gut jetzt sind es nur noch 7 Min., aber allem Anschein nach war es das. Gesundheit 100% der andere Wert 15%. Also im grünen Bereich - noch (*g*) jetzt 100 / 0 Alle Quellen abgefragt und jetzt müsste der Stretch anfangen. Jedenfalls war es vorher so. Tut es aber nicht. Alle Statistiklinien sehen schön gerade aus. Naja mit kleinen Zappelungen. So - ich geh mal los und hole Kaffee & Kuchen. Danke Xman, es war wieder mal sehr nett ein Schwätzchen mit dir zu halten. |
Ich muss sagen, bei mir meldet sich NAFC auch immer komisch zu Wort: Zitat:
Zitat:
Selbst wen er einen anderen nehmen würde --> o.0 Und funkionieren tut NAFC ansonsten gut. :D Jedenfalls gibts diese iphlpapi.dll bei mir garnicht. :Boogie: EDIT. Man gibts da viel auszustanzen (************** u.v.m.) |
@Jok3r wie ich das sehe verbindest DU Dich nur über Kad! ;-) ...Aber das nur nebenbei... Es muß zweimal überprüft werden aus einem einfachen Grund: beim ersten Anbinden von NAFC an einen Adapter wird die LAN-IP verwendet. Mit diieser Anbindung wird praktisch initialisiert. Je nachdem über welche Treiber (PPPoE)/Router und über welches OS Du ins INet gehst kann diese Zuweisung aber falsch sein. Darum muß die richtige IP in Erfahrung gebracht werden und erst dann kann der wirklich richtige Adapter angebunden werden. (was zumindest in 99.99% der Fälle klappt, für die restlichen Fälle kann der Adapter manuell in der preferences.ini eingestellt werden). |
Ok, alles klar! *räusper* Bis auf, was es mit der iphlpapi.dll Zitat:
Und dieses "inet maybe down", als ich das dass erste mal gelesen habe, dacht ich schon der Esel wär im Nirvana. Könnte (X)man das nicht etwas sanfter formulieren, wenn es so berechenbar auftaucht? :-) Zitat:
Oder war das vieleicht irgendwie ein Wink mit dem Zaunpfahl?? |
iphlpapi.dll ist die Windows-Komponente mit der man abfragen kann wievielel Daten über einen Netzwerkadapter laufen. Diese dll bietet mit also die benötigte Schnittstelle. Zitat:
Zitat:
|
Warum soviele Popups mit identischer IP Zitat:
Wenn vor der Ausgabe der Meldung ein Vergleich gemacht würde UND bei Feststellung einer weiterhin identischen IP kein Popup erzeugt würde, DANN hätte ich doch nicht stundenweise Meldungen mit identischer IP ???? |
wo wird ein popup erzeugt ? *Bahnhof* Also nochmal: wurde über 2 Sekunden (Standardwert) kein Upload-Datenpacket gesendet, dann wird die IP angefragt. Sobald man die IP als Antwort erhält bekommst Du die besagte Meldung. Anschließend wird diese IP mit der alten IP verglichen. Solltest Du eine neue IP haben kommen weitere Meldungen. |
Zitat:
... und zwar leider auch dann wenn die IP unverändert ist :-((( Das kommt daher, dass unser geschätzter Guru in BaseClient.cpp bei CUpDownClient :: ProcessPublicIPAnswer eben leider nicht prüft, ob die IP geändert hat, den Log Eintrag (unnötigerweise) immer generiert und dadurch das PopUp kommt... Auf Wunsch kann ich den korrigierten Code liefern :i: |
Zitat:
|
Zitat:
|
Oder ein Häkchen in Options > Notifications > Pop out when (Log entry added) Also erst nen Häkchen machen, dann klappts auch mit dem pop out. |
tja, da muß ich wohl gestehen, daß ich gar nicht wußte, daß es so ne Popup Funktion gibt. Dennoch bleibt es wie es ist.. denn wer diese Meldung ständig bekommt der hat echte Uploadprobleme und die soll er erst mal in den Griff bekommen. |
Zitat:
1. DER Guru hat immer Recht. 2. Sollte er einmal irren so gilt Regel 1 :P Ich habe keine Uploadprobleme, sondern eine schwache Anbindung und die Clients nehmen einfach häufig nicht ab, und dagegen gibts kein Kraut ausser man würde extra einen Renner mit in die Verteilung aufnehmen... Und es ist nun wirklich nicht einzusehen warum man für alle diese Fälle einen Logeintrag machen sollte. PUNKT und für mich erledigt. |
Tja - wenn der ISP nichts besseres bringt, kann auch der beste Esel nix machen. Dann kann ja der Thread geclosed werden *g* |
@ Häufiges "received an IP: **** NAFC-Adapter will be checked Hatte dies auch eine Zeitlang, musste aber lange daran rumwerkeln bis ich es in den Griff gekriegt habe, waren auch mehrere Ursachen gleichzeitig dafür verantwortlich. Als Endresultat hat sich herausgestellt dass das Modem mit den Anzahl Verbindungen nicht mehr klarkommt obwohl es das jahrelang getan hat. Mein Tip daher: aktuelle ipfilter.dat reduziert insbesondere den schädlichen Datenverkehr, die ICMP Datenpakete von und zum Esel blocken stabilisiert die Verbindung zum ISP. Mit diesen Massnahmen wird der unnötige Datenverkehr geblock und zugleich der UL und DL stabiliesiert weil ja weniger Daten ausgetauscht werden. Was eine aktuelle antilech.dll bringt weis ich nicht, kann aber sicher im Forum nachgelesen werden. Hat man nun diese Massnahmen ergriffen und die Meldung taucht immer noch auf so kann man testhalber die Anzahl Verbindungen und oder DL reduzieren: taucht die Meldung nicht mehr auf so liegts am Modem sofern es vorher mit den gleichen Einstellungen immer geklapt hat. |
ich arbeite gerade an dem zugehörigen Code und hab ne Frage: wenn ihr dieses häufige "received an IP: **** NAFC-Adapter will be checked" bekommt seid ihr da gerade zu einem Server verbunden ? Wenn ja mit High oder LowID ? |
Wenns passiert (bin ja keiner der "Problemkinder") bin ich auf jeden Fall nicht zu einem Server verbunden (generell NIE :D ), und habe eine high ID! Allerdings benutze ich den ScarAngel v 1.8 welcher auf Xtreme v 5.4 nicht 5.4.1 basiert. ;) |
Zitat:
Abhilfe im Code schafft einfach der Vergleich, ob es dieselbe IP ist wie vorher. Den Bugfix willst Du ja offenbar nicht haben *gg*:clap |
danke martin für die Auskunft... allerdings ist es weder ein Bug noch so leicht zu fixen... glaub mir, das Problem (nämlich IP-Änderungen abzufragen) steckt im Detail. |
Zitat:
Wenn der Fix einem Dau wie mir innert 30 Minuten gelungen ist kann es nicht so schwierig sein :beer: :beer: |
nur der "Fix" vom Dau hat zur Folge, daß bei manchen LowID clients nun der NAFC-adapter nicht mehr funzt ;-) |
Zitat:
Wenn man einfach die Meldung unterdrückt und den Rest sein lässt funkt es genau so wie vorher aber die nervige Meldung ist weg... q.e.d. :twisted: |
da hast Du allerdings recht. Aber wie schon gesagt.. ich finds gar nicht so schlecht wenn die Meldung da ist... das soll nich tnur mir helfen zu erfahren wie oft der Code aufgerufen wird... sondern zugleich den Leuten mit falschen Uploadeinstellungen zum Nachdenken bringen. |
übrigens das reask sources after IP change hab ich mal wieder ziemlich umgemodelt. Jetzt gehts für mich wieder ans Testen: IP change mit - nur Kad - nur server - kad + server - keine Verbindung jeweils mit den Variationen: - später kommt Kad hinzu - später kommt server hinzu und das ganze mit den Variationen: - LowID + Kad - LowID ohen kad - HighID + Kad - HighID ohne Kad das ganze kann man noch varieren mit Kad firewalled (wobei ich mir den test bisher immer spare) und das ganze noch variert mit verschiedenen vom OS + Router abhängigen Zeitpunkten wann eine Connection beendet wird(=serververbindungsverlust), wie lange es zum server-reconnect braucht + wie lange es braucht bis eine Kad-Ip-Änderung festgesteltl wird. Man sieht, das dahinter ne ziemliche Komplexität steht, auch wenn der Code im Endresultat dann doch kürzer aussieht. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:07 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.