Moin,
ich hatte vor einiger Zeit hier einen Thread gestartet wegen eines Print-Controllers, der regelmäßig aussteigt. Wir sind noch immer bei der Fehlersuche, genaueres werde ich demnächst für die interessierten Mitleser im alten Thread noch posten.
Wie dem auch sein, folgende Situation hat sich heute ergeben bzw. folgendes wollen wir heute probieren:
Der Controller hat eine vollkommen neue IP-Adresse aus einem anderen Adressbereich bekommen und wurde an eine am Server (Server 2003 SBS) befindliche zweite Netzwerkkarte angeschlossen. Im Betriebssystem wurde das Routing vom "normalen" Netz auf das neue Netzwerk (bestehend nur aus dem Server mit der zweiten Karte und dem Controller) eingerichtet. Einen Windows-Client entsprechend umkonfiguriert, Ping geht, Drucken geht, alles prima, schnell und zu vollster Zufriedenheit des Kunden.
Dann zum Mac (OS X - keine Ahnung, welche Version genau). Unter der alten Konfiguration keine Probleme. Nun wurde der Mac umgestellt auf TCP/IP-Druck anstelle Appletalk, die gleichen Einstellungen wie beim Windows-PC (die eigene IP-Adresse natürlich ausgenommen), damit funktioniert alles, aber gähnend langsam, so langsam, daß an ein Arbeiten nicht zu denken ist. Ein Ping an den Controller ergibt fast 500 ms Antwortzeit!
Kann sich evtl. irgendjemand einen Reim drauf machen, warum der Windows-PC immer noch raketenschnell druckt, der Mac dagegen wie eine Schnecke darherkriecht?
Ich bin jedenfalls mit meinem Latein am Ende.
Alles wieder zurückkonfiguriert, und schon geht auch auf dem Mac alles wieder in gewohnter Geschwindkeit. An den Switches etc. wurde absolut nichts geändert, es wurde halt nur das Routing vorgenommen, was an zwei Betriebssystemen vollkommen extrem unterschiedliche Geschwindkeiten ergeben hat.
Falls jemand einen Geistesblitz hat, wäre ich wirklich dankbar. Das Ding raubt mir noch meinen Verstand.
Gruß
Jürgen
Heimnetzwerke - WIFI, LAN, Router und Co 16.557 Themen, 81.662 Beiträge
Hallo Crusty
Ich glaube die Macuser auf nickles.de können dir bei diesem Problem nicht weiterhelfen. Hattest du es denn schon mal in einem anderen Forum probiert? Empfehlen könnte ich MacUser.de, da wär dann natürlich auch die genaue OS X-Version nötig.
[edit]
eventuell ein Bug, ist denn die Version aktuell?
Mac OS X 10.0 (Cheetah) -> 10.0.4
Mac OS X 10.1 (Puma) -> 10.1.5
Mac OS X 10.2 (Jaguar) -> 10.2.8
Mac OS X 10.3 (Panther) -> 10.3.9
Mac OS X 10.4 (Tiger) -> 10.4.9
die ersten 3 setzt ihr hoffentlich nicht ein..
mfg
chris
Bin leider nicht so der MAC-Freak, aber welcher Druckdienst läuft denn auf dem MAC? Wie sieht es mit DNS im Netzwerk aus?
Moin,
standardmäßig ist der Controller über Appletalk an das Netzwerk angebunden, aufgrund der Probleme mit regelmäßigen Abstürzen des Controllers, die irgendwie mit dem Netzwerk zusammenhängen, die aber trotz 4,5-stündigem Einsatz eines Netzwerkspezis nicht aufzufinden sind (keine erwähnenswerten Fehler über Meßgeräte feststellbar, nichts über einen "Netzwerksniffer"), wollten wir nun versuchsweise auf TCP/IP-Druck (Port 9100) umsteigen - geroutet auf das Zweitnetz. Tja, mit dem genannten Ergebnis: Windows hui, Apple pfui.
DNS läuft über den Windows-2003-Server.
Leider mußte ich gestern dann auch irgendwann abbrechen und hatte gestern leider auch ausnahmsweise mein Notebook nicht zur Verfügung, ich hätte ja noch gerne getestet, wie sich das Notebook (XP) verhält, wenn es statt des Macs angeschlossen wird.
Appletalk habe ich leider nicht geroutet bekommen. "Mein" Netzwerk-Spezi kennt sich leider auch nur mit Windows aus, der Mac-Spezi nicht mit Windows-Server-Spezialitäten, ich stehe irgendwo dazwischen und verstehe bald gar nichts mehr. Alles, was in der Therorie so gut klappen sollte, versaut mir wieder irgendwas anderes.
@crissv2
Danke, an das Forum wollte ich mich heute auch wenden (und vielleicht noch an www.netzwerktotal.de), dazu wollte ich aber erstmal die genau eingesetzte Version ermitteln (wie auch von dir als Voraussetzung angegeben), die hauen mir ja vermutlich sonst gleich den Schädel ein, spätestens vermutlich dann, wenn ich mich als sonst-nur-Windows-User outen muß :-) Ursprünglich wollte ich die Frage hier auch gar nicht stellen, aber manchmal sieht man den Wald vor lauter Bäumen nicht und deshalb habe ich die Frage doch erstmal gestellt.
Wenn die Situation nicht so traurig wäre (uns fehlen die rund EUR 30.000, die der Kunde immer noch zurückhält, doch ziemlich), dann könnte man glatt drüber lachen.
Mal sehen, nach dem Rückbau auf den alten Zustand habe ich am Controller noch ein paar nicht benötigte Dienste/Protokolle abgeschaltet, vielleicht bringt das ja auch was. Oder irgendeiner der schon mit dem Problem involvierten Spezis hat noch eine Idee. Dumm halt, daß sich von denen jeder nur in seiner Materie gut auskennt.
Danke erstmal für's zuhören.
Gruß
Jürgen
Appletalk ist afair nicht routingfähig, das hätte also gar nicht geklappt. Ich hätte da noch ein paar Fragen: Ist der MAC im DNS eingetragen und ist der DNS auf dem MAC eingetragen? Wird Port 515 auch geroutet? Wie sind die Einstellungen der Druckwarteschlange (RAW, LPR)?
Wenn alles nicht klappt, dann würde ich mal folgendes testen:
Gib den Drucker mal von einem Windows-Rechner im Netz aus frei und binde ihn dann testweise darüber vom MAC aus ein.
Danke für die Rückmeldung, seltsamerweise konnte man am Server was von Appletalk-Routing einstellen, wenn man allerdings davon (so wie ich) keine Ahnung hat, verwundert es nicht weiter, daß das doch nicht geklappt hat.
Der Drucker lief über RAW, die Antworten auf DNS muß ich derzeit leider schuldig bleiben, werde sie aber im Hinterkopf behalten.
Gib den Drucker mal von einem Windows-Rechner im Netz aus frei und binde ihn dann testweise darüber vom MAC aus ein.
Das hat der Mac-Semi-Profi, den ich gestern zur Hand hatte, probiert, hat es allerdings nicht hinbekommen. Am MAC bin ich selbst ja eine hoffnungslose Niete, aber ich werde mal nachsehen, ob ich dazu eine Anleitung finde. Gedacht hatten wir ja schon daran, auf dem Server freigeben und darüber drucken.
Es wird sich heute noch ein Netzwerk-Spezialist vom Hersteller melden, der wird sich auch direkt mit dem Apple-Semi-Profi unterhalten, mal sehen, ob die noch was klären können. Ich behalte deine Fragen/Ideen mit im Hinterkopf, vielleicht läßt sich daraus ja was zaubern.
Danke soweit!
Gruß
Jürgen
Wenn gar nichts mehr geht: am Server den Drucker installieren und per LPR-Port (Unix-Druckdienste) freigeben.
Darauf müsste der MAC auch zugreifen können.
Aber das IP-Problem ist damit noch nicht gelöst - denn SO dürfte das nicht sein. So wie die Sache jetzt aufgebaut ist, isses aber trotzdem suboptimal...
Wo tritt die erhöhte Latenz auf? Am Router? Am Printserver? Ist das auch bei anderen Devices in anderen Netzbereich so?
Kannst Du den alten Thread mal verlinken - finde ihn grade nicht.
Moin,
der Link zum alten Thread: http://www.nickles.de/static_cache/538240752.html
Der Printcontroller (derzeit im normalen Netzwerk eingebunde) schmiert jeden Tag mehrmals ab, manchmal läuft er stundenlang durch, manchmal stürzt er in der Stunde zweimal ab. Es liegt definitiv nicht an einem defekten Controller, der wurde testweise schon mit einem anderen Kunden getauscht, der Fehler bleibt hier, beim anderen Kunden läuft alles. Einzige Auffälligkeit: Der Controller stürzt jeden Morgen um 7.15 (+/- weniger Minuten) ab, nämlich dann, wenn der erste Mitarbeiter im Lager seinen PC startet.
Am Stromnetz liegt es nicht, das können wir jetzt ausschließen. Der Controller läuft, wenn er über ein Cross-over-Kabel direkt mit einem Mac verbunden ist, aber das ist natürlich keine Lösung. Netzwerkfehler waren von einem Profi (gehe ich jedenfalls mal von aus, immerhin gibt er auch Netzwerkschulungen und hat das nicht zum ersten mal gemacht) keine gefunden worden. Der oben erwähnte PC wurde mehrmals aus- und wieder eingeschaltet, kein Absturz erfolgt mit einer Ausnahme, aber auch da war unmittelbar vor dem Absturz nichts ungewöhnliches im Netzwerk zu finden.
Der Controller läuft auch einwandfrei, wenn er zum Test nur an einem nicht weiter verbundenen Switch hängt. Es kommt also definitiv irgendwas aus dem Netzwerk, aber es ist um's Verrecken nicht festzustellen, was genau. Switch, Anschlußdose, Stromsteckdose, Netzwerkkabel, es wurde alles schon getestet. Übertragungsgeschwindkeit fest eingestellt. Testlauf über einen DLAN-Adapter. Anschluß über einen Netzwerk-Hub, nichts hat geholfen.
Der Hersteller will einen Spezialisten schicken, aber erst in ca. 2 Wochen. Derzeit herrscht vom Hersteller die Einstellung, es liegt am Netzwerk (Controller wurde ja schon getauscht), damit ist es ein Problem des Kunden. Der Kunde beharrt darauf, daß das Gerät auf irgendwas reagiert, was kein anderes Gerät beeinträchtigt, damit ist das Gerät fehlerhaft. Die Wahrheit liegt vermutlich irgendwo in der Mitte, der Controller reagiert überempfindlich, das steht für mich auch fest. Warum, das weiß ich nicht. Aber wo ich hier die Grenze ziehen soll (wer hat zu 49 %, wer hat zu 51 % recht?), das weiß ich beim besten Willen nicht.
Irgendwie müssen wir das Gerät zum laufen bekommen, egal wie, sonst haben wir es bald wieder auf dem Hof stehen und als kleine Firma können wir uns so ein Experiment nicht leisten, immerhin geht es hier um 30.000,- Euro.
Daher der Versuch, über das Routing ein zweites Netzwerk zu errichten, um (zumindest in der Theorie) das "Störsignal" (ich nenne es jetzt einfach mal so) außen vor zu lassen. Hat ja auch mit Windows perfekt geklappt, der Controller hat ruckzuck gedruckt. Ob da ein paar Sekunden bei drauf gehen, das interessiert nicht ganz so sehr, ob ein Ausdruck eine Minute oder 1 Minute und 7 Sekunden dauert, das ist egal. Aber eine Grafikdatei, die normalerweise nach etwa einer Minute rauskommt, nach 3 Minuten erst zu einem Prozent übertragen zu haben, das geht nicht. Und ich habe absolut keine Erklärung dafür, es übersteigt aber auch meine Netzwerkkenntnisse.
Erschwerend kommt hinzu, daß einem Rückrufe versprochen werden, die nicht erfolgen und so weiter, und so fort. Morgen möchte ich nochmal mit dem Netzwerk-Spezialisten telefonieren, mit dem ich beim Kunden war (der auch das Netzwerk überprüft hat), vielleicht fällt dem ja noch was ein, was man noch versuchen könnte.
Derzeit ist halt die Frage überhaupt: Warum wird ein Windows-PC mit IP 192.168.27.76 problemlos und ohne merklichen Geschwinkeitksverlust geroutet, warum ist der Mac (OS X 10.4.9) mit der 192.168.27.100 so verflucht langsam? Ein Ping vom Mach an den Controller ergab fast 500 ms Antwortzeit. Ich weiß es leider nicht, ich weiß aber auch keine andere Lösung, um überhaupt aus dieser Scheiß-Situation rauszuommen, wenn das nicht läuft. Ich bin auch nicht der Server-Spezialist und mit Routing hatte ich (abgesehen von der Konfiguration diverser DSL-Router) noch nie was zu tun. Ich hab' halt andere Fachgebiete. Was ich noch testen werde, ist ein Notebook (mit XP), welches ich mal mit den Einstellungen des Macs ersatzweise an dessen Netzwerkdose hängen werde.
Der allerletzte Versuch wäre noch, den PC, der um 7.15 gestartet wird, gegen ein anderes Gerät zu tauschen, oder zumindest mal die Netzwerkkarte. Mein Bauchgefühl sagt mir aber, daß das nicht helfen wird.
Scheiße, man hat eine in der Theorie richtig gute Idee, aber irgendwo in der Praxis hakt es. Es funktioniert ja, aber halt so unendlich langsam.
Ja, das war's erstmal, was ich derzeit an Erkenntnissen/Fragen/Probleme habe.
Gruß
Jürgen
Hallo Crusty, hing der Printserver auch schon mal an einem Switch statt einem Hub? Der Hintergrund der Frage zielt darauf ab, ob das Grundproblem auf der physikalischen Netzwerkschicht liegt, oder ob das Problem auf einer höheren Ebene zu finden ist.
Noch eine Frage, der Client, welcher um 7:15 online geht, ist das zufällig noch ein WindowsNT 4.0?
Und weil´s so schön ist gleich noch eine: Habt ihr an dem MAC mal einen traceroute abgesetzt auf den Printserver?
Nabend,
das mit den Benachrichtigungsmails scheint ja gar nicht mehr zu klappen... :-(
Im normalen Betrieb hängt alles im Netzwerk (incl. Controller) an insgesamt 3 oder 4 Switches, der Hub ist nur mal in der Testphase dazugekommen, man hat sich ja an jeden Strohhalm gehängt.
Noch eine Frage, der Client, welcher um 7:15 online geht, ist das zufällig noch ein WindowsNT 4.0?
Nee, der läuft unter XP. Was hättest du denn bei NT für eine Idee gehabt?
Habt ihr an dem MAC mal einen traceroute abgesetzt auf den Printserver?
Ich vermute, du meinst im "gerouteten Zustand" (der ja derzeit wieder zurückgebaut ist)? Nein, leider nicht, werde ich aber mit auf meine To-do-Liste setzen. Ich mußte gestern ja leider auch abbrechen, ich hätte schon noch ganz gerne eine halbe Stunde drangehängt, ging aber nicht. Auf ein traceroute wäre ich vermutlich aber auch nicht gekommen.
Gruß
Jürgen
Okay, wenn das Problem auch hinter Switches auftritt, dann scheidet alles auf der physikalischen Ebene schon mal komplett aus und es bleiben nur noch die höheren Schichten als Fehlerquelle übrig.
Nee, der läuft unter XP. Was hättest du denn bei NT für eine Idee gehabt?
Ich habe mal eine blöde Erfahrung mit NT 4.0 SP6a, EMF als Protokoll und einem Intel-Printserver gemacht, war nur so eine Idee.
Ich vermute, du meinst im "gerouteten Zustand"
Ja, im gerouteten Zustand. Es wäre mal interessant zu sehen wo es anfängt zu hängen, ob schon vor dem routenden Server, oder erst danach. Wenn es bereits vorher passiert wäre auch ARP ein möglicher Fehlerkandidat gewesen.
Was mir jetzt eigentlich noch als einziges so spontan einfällt: Es gibt die Option bei Windows "Beim Start nach freigegebenen Ordnern und Durckern im Netzwerk suchen". Eventuell lässt sich der Absturz ja zumindest eingrenzen, wenn man diese Option bei dem 7:15-Rechner mal deaktiviert. Zumindest könnte man dann sehen, ob es dieser Rechner ist (denn da die physilaische Schicht als Fehlerursache ausfällt kann er ja erst bei einem Verbindungsversuch den Printserver "killen").
Streich das mit ARP, das war Blödsinn. Man sollte so spät nciht mehr posten ;o)
OK - da die Traceroute noch aussteht können wir das Routingproblem so erstmal nicht lösen; aber wirklich interessant ist ja die Frage was den Printserver aus dem Tritt bringt.
Einen Fehler auf Layer 1/2 können wir denke ich ausschließen, da sowohl Switchport/Hub/... und Printserver schon getauscht wurden.
Interessant wirds also erst dann wenn ein Protokoll ins Spiel kommt.
Wenn der Zusammenhang mit dem ersten PC tatsächlich reproduzierbar ist mach mal folgendes: häng einen kleinen Hub an den Switchport vom Printserver, an den dann den Printserver und dein Notebook, auf dem Du zum fraglichen Zeitpunkt dann Wireshark oder den Microsoft Network Monitor 3.0 laufen lässt und mal lauschst was so kommt.
Nur mal so als Idee... was für ein Mainboard und was für eine Netzwerkkarte hat der "verdächtige" PC? Es gab z. B. von Asrock mal einige Mainboards mit onboard LAN die die MAC-Adresse 00-00-00-00-00-00 hatten (so blöd muss man als Hersteller erstmal sein) - sowas könnte ich mir eventuell noch als Fehlerquelle vorstellen.
Guten Morgen,
erstmal vielen Dank an alle, die sich mit mir den Kopf zerbrechen.
das "traceroute" werde ich sicher noch ausprobieren, das ist eine gute Idee.
Es gibt die Option bei Windows "Beim Start nach freigegebenen Ordnern und Durckern im Netzwerk suchen".
Durchaus etwas, was man checken kann bzw. sollte. Allerdings ist der Drucker nicht freigegeben, andererseits könnte es ja auch nur die Suche danach sein.
Wenn der Zusammenhang mit dem ersten PC tatsächlich reproduzierbar ist mach mal folgendes: häng einen kleinen Hub an den Switchport vom Printserver, an den dann den Printserver und dein Notebook, auf dem Du zum fraglichen Zeitpunkt dann Wireshark oder den Microsoft Network Monitor 3.0 laufen lässt und mal lauschst was so kommt.
Wireshark lief mit professioneller Beobachtung (incl. 2 Abstürzen) 4,5 Stunden nebst Gegenkontrolle mit einem Netzwerkprüfgerät sowie weitere knapp 2 Tage noch nebenbei. Es ist absolut nichts feststellbar, was einen weiterbringen würde, selbst der Netzwerkverkehr unmittelbar vor einem Absturz (anhand eines Dauerpings gut erkennbar, wann der Controller abstürzt) ist jedes mal ein anderer. Das ist ja das Verfluchte an der Sache.
Ich werde mir mit euren Ideen noch ein paar Gedanken machen und noch ein paar Tests vornehmen, evtl. kann ich auch die Netzwerkkarte am 7-Uhr-15-PC austauschen (da muß ich ja auch erstmal mit dem Admin des Kunden drüber einig werden).
Ich lasse euch wissen, wenn sich neue Erkenntnisse ergeben.
Viele Grüße sendet
Jürgen
und hoffentlich, hoffentlich, hoffentlich auch Endergebnis.
Tja, da war ich nun heute beim Kunden. Das Routing wieder hergestellt, Windows-PC getestet, sehr schnell, Ping unter 1 ms. Prima.
Dann zum Mac. 1 Depp (ich, jedenfalls, was Mac angeht), 1 Mac-Anwender, 1 Systemadministrator mit sehr wenig Mac-Kenntnissen (kaum besser als meine). Irgendwann haben wir den Ping-Befehl gefunden, tja, das Ergebnis möchte ich euch nicht vorenhalten:
Es ist mir außerordentlich peinlich und wirklich sehr unangenehm, hier eine falsche Fährte gelegt zu haben. Bitte nicht hauen, ist mir wirklich unangenehm: Es waren nicht 491 ms, sondern 0,491 ms. Das kommt davon, wenn man sich auf die Aussage von Dritten verläßt und beim Blick über die Schulter nur die Nachkommastellen sieht... Nun ja, der Wert ist ja tadellos. Räusper (dabei unauffällig den Blick im Raum umherschweifen lassen und etwas verlegen aussehen).
Also wieder TCP/IP-Druck (Port 9100 und LPR, beides getestet), laaaaaaaaaaaangsam. Trotz des guten Pings miserable Geschwindigkeit bei der Übermittlung der Druckdaten.
Dann bin ich gedanklich noch mal all eure Ratschläge durchgegeben und habe ich dann an die Druckerfreigabe erinnert. Treiber auf dem Server installiert, freigegeben, die 3 von der Tankstelle dann wieder vor'm Mac und mit Hilfe von Google erstmal schlaugelesen, wie man denn auf freigegebene Drucker zugreift (oh wie peinlich...), die neu erworbenen Kenntnisse in die Praxis umgesetzt, Testdruck gestartet und die Kiste geht ab wie eine Rakete. Warum es über den Umweg mit dem Server extrem deutlich schneller geht als mit einer direkten Verbindung, das weiß ich beim besten Willen nicht, die Kernaussage dieses Threads ist also durchaus richtig, trotz meines Irrtums. Aber das soll uns egal sein, solange die Maschine läuft.
Tja, jetzt bleibt nur noch abwarten. Wenn die Kiste bis Montag abend keine Zicken mehr macht, wird es das wohl hoffentlich gewesen sein. Und wenn nicht, dann wissen wir auch nicht mehr weiter.
Also, nochmal allerherzlichen Dank an eure Tips, Ratschläge und Informationen, gelernt habe ich einiges. Etwas Daumendrücken in den nächsten Tagen kann übrigens nicht schaden :-)
Falls irgendjemand rein zufällig noch wissen möchte, von was wir hier eigentlich die ganze Zeit geredet haben, findet hier die Antwort darauf: http://www.canon.de/For_Work/Products/Professional_Print/Controllers__RIPs/imagePRESS_Server_Q1/index.asp in Verbindung mit http://www.canon.de/For_Work/Products/Professional_Print/Digital_Colour_Production/imagePRESS_C1/Index.asp
Danke an alle!
Jürgen
Ja, er lebt noch, er lebt noch, er lebt noch (auch noch rund 1,5 Stunden nach den berühmten 7.15 Uhr).
Irgendwas ist anders, alles was anders ist, ist gut. (Bill Murray in "Und täglich grüßt das Murmeltier")
Gruß
Jürgen
Freut mich zu hören das es doch noch geklappt hat.
mfg
chris
.... Holz Controller..... *lol*
Dann kannst du dir ja Hoffnungen machen, dass die Knete bald reinkommt :-)
Gruß
K.-H.
Yo, mich freut's auch und Hoffnung auf die Kohle besteht nun auch allmählich. Zeit wird's.
Gleich mal auf Holz klopfen...
Gruß
Jürgen
