2.0.1 Fehlermeldungen vom Netz in der CONFIG.SYS?
2.0.2 Ich kann mich nicht am PEER anmelden
2.0.3 Requester bzw. Server startet nicht.
2.0.4 Probleme mit einer 3C509
2.0.5 Netzwerkkarten allgemeine Warnung
2.0.6 Ich kann nicht mehr als 2 Comports sharen
2.0.7 Fehler automatische Medienerkennung
2.0.8 Win95 druckt nicht auf den OS/2 Netzwerkdrucker
2.0.9 COMPEX RL2000 oder der Haken mit dem PnP
2.1.0 Probleme mit IBM-Lanstreamer Token Ring Karten
2.1.1 Wie kann ich einen bestehenden Internetzugang von OS/2 unter WinOS/2 nutzen?
2.1.2 SIOCADDRT: Kein Zugriff auf das Netzwerk;
2.1.3 Netzwerk mit 2 Rechnern (100Mbit) über Crossoververkabelung.
2.1.4 Probleme mit NT4 + SP3
2.1.5 TCPBEUI die Sache mit dem NAMEFILE und SYS00053
2.1.6 Die Installation bleibt hängen
2.1.7 Installation über NETZWERK klappt nicht
2.1.8 MPTS kann nicht gestartet werden da es angeblich schon leuft
2.1.9 Unbekannter Fehler 205
2.2.0 Kann ich das PEER etwas optimieren ?
2.9.0 Fehlersuche
Erscheinen bereits beim Abarbeiten der CONFIG.SYS Fehlermeldungen, liegt der Fehler wahrscheinlich am Netzwerktreiber oder an den Einstellungen für die Protokolle. Verwendest du Warp Connect 3 und Netbios über TCP/IP, schaue mal in 1.4.3.
Sind alle Dateien vorhanden und treten beim Booten immer noch Fehlermeldungen auf, ist die radikalste, aber wahrscheinlich erfolgreichste Methode eine Neuinstallation der Protokolle. Starte MPTS.EXE, wähle Konfigurieren, LAN-Adapter und Protokolle und entferne alle Protokolle und Netzwerktreiber.
OK, nun das ganze umgekehrt: Netzwerktreiber installieren, Protokolle wieder an den Adapter binden mit »Hinzufügen«. Die Protokolle sind jetzt auf Defaultwerten, darum im Kasten »aktuelle Konfiguration« ein Protokoll markieren, auf »Editieren« klicken, um beispielsweise Netbios anzupassen oder Netbios über TCP/IP zu konfigurieren.
Ist alles eingestellt, dann OK klicken. Steht hinter der Zeile NETBIOS SOCKET ZUGRIFF nicht KONFIGURIERT, den runden Schalter davor klicken, dann »Konfigurieren« klicken. Jetzt sollte alles soweit richtig sein. »Schließen« klicken und nicht vergessen, die Konfiguration und die CONFIG.SYS sichern zu lassen.
Kommt nach der Nachinstallation von Netbios ueber TCPIP immer der Fehler:
LT00136
Es liegt an (von MPTS automatisch) falsch eingetragenen Werten in
der Protocol.ini.
Folgende Werte müssen geändert werden: |
---|
[tcpbeui_nif] SESSIONS = 130 NCBS = 225 NAMES = 21 PACKETS = 50 |
Oder es MPTS noch einmal versuchen lassen .
MPTS beenden und Einstellungen sichern lassen
Neu starten , in den meisten Fällen geht es jetzt .
Die CONFIG.SYS wurde ohne Fehlermeldung abgearbeitet, der Befehl NET START REQ wurde ausgeführt, ohne daß es zu einer Fehlermeldung kam. Befehl LOGON USER /P:PAßWORT oder nur LOGON mit anschießender Abfrage wurde korrekt eingegeben. Als Antwort bekommst du immer nur eine Fehlermeldung, daß der LOGON gescheitert ist.
Wenn es OS/2 Warp Server oder Warp 4 ist, kann es sein, daß dich ein BUG der Installation erwischt hat. Für die deutsche Version melde dich beim System an mit:
Nun mit der Benutzerverwaltung deinen Administrator-Account neu anlegen.
Das System lief bisher und nun auf einmal kommst du nicht mehr rein ?
Wenn du kein Backup von NET.ACC hast, dann gibt es jetzt noch 2 Möglichkeiten . Entweder versucht man mit der Reserve \IBMLAN\INSTALL\NET.ACC wieder rein zu kommen mußt du jetzt in den Erste-Hilfe-Koffer greifen.
Darin ist eine NET.ACC für Warp Connect und Warp 4 enthalten (nicht für den Warp Server ).
Dafür sorgen, daß die NET.ACC nicht gesperrt ist, dazu frisch booten und das Netz nicht starten (in der STARTUP.CMD auskommentieren, falls der Requester dort gestartet wird). Jetzt die x:\IBMLAN\ACCOUNTS\NET.ACC durch meine Version ersetzen. Netz mit NET START REQ starten. Wenn das ohne Fehler geht, solltest du dich jetzt als USER ADMIN ohne Paßwort einloggen können. Nun mußt du deine User-Accounts neu anlegen.
Und dann mach besser mal ein Backup von NET.ACC. Schlagt dazu mal
in der Onlinedoku von Warp nach was die zu den Programmen BACKACC.EXE
, RESTACC.EXE und FIXACC.EXE zu sagen hat.
Wenn der Dienst gestartet werden soll, erscheint nur .......................................... - und das ewig.
Der Requester versucht auf das LAN zuzugreifen. Wenn kein Netzwerkkabel angeschlossen ist, führt das bei manchen Karten zu obigem Effekt.
Das Netzwerk will mit der Karte nicht laufen. Mögliche Fehler sind ein alter Treiber und eine falsche Einstellung der Karte.
Die automatische Erkennung der Karte geht bei mir erst ab NDIS 3.0, das ist bei WARP 4 dabei. Oder du saugst es bei 3COM oder requestest bei 2:2476/30 3C5X9.ZIP
Setze die Maximum Modem Speed auf 9600. Wenn ich das höher einstelle, kommt es bei mir zu seltsamen Effekten bis zum völligen Versagen der Karte. Du kannst deshalb trotzdem ohne Probleme ein 28k8-Modem oder 64K-ISDN über Netz betreiben.
Die Karteneinstellungen nie mit mit den Setup-Utilitys ändern, wenn der Netzwerkkartentreiber geladen ist.
Das
kann für die Karte tödlich enden. Nach einigen Tests musste
ich zwei NE2000 Bords in die Mülltonne werfen .
Wer aber noch eine NE2000 hat und sich sowiso was anderes kaufen will kann es ja gerne mal testen :)
Kommt beim Drucken auf einem Drucker, der an einen Peer/LAN-Server hängt immer die Meldung "Drucker offline" oder etwas in der Richtung dann überprüfe auf den WIN-Rechner mal die Einstellungen für den Spooler.
DRUCKAUFTRÄGE in WARTESCHLANGE STELLEN
Zu finden beim Druckerobjekt unter EIGENSCHAFTEN \ Details \ Spooler-Einstellungen.
Beim Einsatz des Fabrikates COMPEX RL2000 PCI(V.1.2c) fuer den
PCI-BUS ist es zum Beispiel passiert, daß die PCI-Karte
'glaubte', sie sei an einem Twisted-Pair-Kabel angeschlossen,
*obwohl* sie mit einem Koax-Kabel am BNC-Anschluß und einem
Terminator beim Booten versehen war (die Karte bietet Anschlüsse
für beide Kabeltypen). Dies ist besonders tückisch, da die
PCI-Karte unmittelbar nach dem Einsetzen und Neubooten sofort
erkannt, IRQ und I/O richtig gesetzt, die korrekten OS/2-Treiber von
der mitgelieferten Diskette installiert und problemlos geladen wurden
und das Mounten (ummappen auf andere LW-Buchstaben) von Laufwerken
innerhalb dieses Rechners hervorragend klappte.
*Noch mehr in die
Irre führend war eine Meldung des Treibers beim Booten, die auf
mögliche Kabelprobleme hinwies. Diese Meldung _verschwand_,
nachdem das bis dahin noch freie Ende des BNC-Kabels ebenfalls mit
einem Terminator versehen worden war!* BR> Zum Glück gibt es
für diese PCI-Karte ein Programm, mit der man deren
Einstellungen überprüfen und notfalls ändern kann
(EASYSET.EXE; liegt der auf der mitgelieferten Diskette und läuft
nur unter Plain-DOS), einschließlich der fehlerhaften
Einstellung bezüglich des Kabels.
Fazit: Wenn immer
möglich, die selbst gefundenen Einstellungen einer PnP-Karte mit
externen Programmen überprüfen, ob sie auch mit der
Realität übereinstimmen!
Kleiner Nachtrag: Nach
der Beseitigung obiger 'Tücke' arbeitet die Karte ganz
hervorragend mit einem entsprechenden Gegenstück für den
ISA-BUS (Compex RL2000A-PnP) und erstaunlich flott. Auch die
Treiberausstattung beider Karten ist *vorbildlich* und sie werden
unter WARP 4 sofort gefunden und eingebunden. Trotz obiger Kritikam
PCI-Modell sind diese Typen offenkundig hervorragend für den
Einsatz unter OS/2 geeignet (Kostenpunkt Aug. 1997: ca 55,- für
die ISA-, ca. 130,- DM fürdie PCI-Ausfuehrung).
(von
Klaus Kulbarsch)
Das Problem:
Sie finden die benötigte WINSOCK.DLL im Verzeichnis
\TCPIP\DOS\BIN. Kopieren sie diese Datei in das Windows
Systemverzeichnis \OS2\MDOS\WINOS2\SYSTEM.
Nachdem ich unter Warp 4 TCP/IP installiert hab, bekomme ich folgende Meldung beim Booten:
SIOCADDRT: Kein Zugriff auf das Netzwerk; SIOCADDRT: Kein Zugriff auf das Netzwerk; Fortsetzung --> Eingabetaste druecken |
Verantwortlich ist dafür in der Regel x:\mptn\bin\setup.cmd. Diese Datei mal in vom einer Komandoizeilensitzung aufrufen und nachsehen ob sie die oben erwähnten Meldungen produziert. Wenn ja gibt liegt es in der Regel an den ROUTE- Eintägen und es gibr mehrere Ursachen.
Die Route ist schlicht und einfach falsch,
es wird auf ein Netzwerk geroutet welches im Moment nicht erreichbar ist,
die Netzwerkkarte arbeitet nicht richtig und TCP/IP konnte erst gar nicht an den Adapter gebunden werden.
Für 1 und 2 gilt es die Verbindung zum Netzwerk herzustellen oder die ungültigen Einträge in der setup.cmd entfernen, ob ihr das mit einem Editor oder über tcpcfg.exe macht ist eure Entscheidung.
Bei 2 Rechnern, die mit 10/100 Mbit Netzwerkkarten verbunden sind, muss zumindest auf einer Karte die automatische Geschwindigkeitserkennung deaktiviert werden. Wenn die auf beiden Karten aktiv ist, geht es oft nicht. Besser ist es wenn man es im Kartensetup direkt und fest einstellen kann.
Bei NT wird ab SP3 das die Anmeldekennung verschlüsselt übertragen, der LAN Server und SAMBA sind jedoch auf den neuen Streich von MS noch nicht ausgerichtet.
Regedt32 aufrufen
HKEY-LOCAL_MACHINE\system\CurrentControlSet\services\rdr\parameters
Wert hinzufügen: EnablePlainTextPassword
Datentyp: REG_DWORD
Daten: 1
Damit sollte die Kennung wieder im Klartext übertragen werden und das Problem beseitigt sein.
2.1.5 TCPBEUI die Sache mit dem Namefile und SYS00053
Hier jedoch noch eine kleine Anmerkung zum Parameter NAMESFILE in der Protocol.ini. Standardwert für NAMESFILE ist 0 also inaktiv ,manche setzen es auf 1 also wird nur ein Eintrag (der erste) aus der RFCNAMES.LST gelesen.
Wenn also 10 Rechner in der RCFNAMES.LST eingetragen werden muß NAMEFILES auf 10 erhöht werden.
Zugriffsversuche (NET USE bzw. NET VIEW) auf einen Server, der nicht von Namefiles abgedeckt wird, endeten mit einem SYS00053.
2.1.6 Intallation bleibt hängen
Auf manchen Rechnern kommt es vor das die Installation bei der Netzwerkkonfiguration / Installation hängenbleibt, die Ursache dafür ist nur schwer zu lokalisieren. In solchen Fällen helfen Geduld und Handarbeit.
Ein scheinbarer Hänger kann z.B. sein wenn Warp behauptet, daß es am »konfigurieren / aktualisiereren« sei, dies kann je nach Rechner durchaus bis zu 10 Minuten dauern, ohne daß Warp seine Aktivitäten durch Festplattenzugriffe oder ähnliches zu erkennen gibt.
Wenn sich trotz aller Geduld nichts mehr rührt oder die Installation gar mit einer Fehlermeldung abgebrochen wird, kann man sich auf den Kopf stellen und versuchen herauszufinden, was die Ursache des Fehlverhaltens ist oder einfach das vorgesehene Installationprogram umgehen und die Installation von Hand erledigen.
Installiert werden muß in der Reihenfolge:
Warp (ohne Netzwerksupport)
Die LAN-Adapter und Protokolldienste MPTS
das Peer
Bedarf TCP/IP
Zu finden sind die Komponenten auf der WARP CD unter:
MPTS |
\CID\IMG\MPTS\INSTALL.CMD |
Peer |
\CID\IMG\IBMPEER\PEERRMT.EXE |
TCP/IP |
\CID\IMG\TCPAPPS\INSTALL.EXE |
Wenn MPTS installiert und konfiguriert wurde, muß OS/2 neu gestartet werden bevor TCP/IP oder das Peer installiert wird !
PROBLEM:
Netzwerkinstallation von WARP über NETZWERK scheitert, der Server wird nicht gefunden » XI10056: Der Server-Name PQ6FT9Q3 kann nicht gefunden werden. »
Dauer der Fehlersuche und Problemlösung 3 E-Mails.
DerWeg zur Lösung :
Auf den Startdisketten wird die lantran.log überprüft, es werden keine IRQ-, I/O-Konflikte oder Fehler beim Binden der Protokolle festgestellt => Startdisksatz des Client scheint O.K. zu sein
Überprüfen des Codeserver auf Funktion. Auf der HD sollte es was geben, das sich \IBMINST\TABELS\SERVICE.INI nennt. Bastelstunde angesagt: Test, ob der Server überhaupt arbeitet. HD mit OS/2 ist D:, CD-ROM ist F:. Nun starten wir mal den Server von Hand.
D: d \IBMINST\TABLES f:\CID\SRVIFS\SERVICE.exe /INI=SERVICE.INI
>Statusabfrage des Servers F:\CID\SRVIFS\SERVICE.EXE /INI=SERVICE.INI /STATUS SERVICE Statusbericht Version 1.32.4 Server-Name = PQ6FT9Q3 Gruppenname = NO Adapter = 0 Aktive Clients = 8 Clients - Max. = 5 Dateien - Max. = 9999 Geöffnete Dateien = 0 Berechtigungen = NO Systemabschluáanforderungen = NO Aliasname R/W PERCLIENT Pfad Default Yes No F:\ CDROM No No F:\ STATUS Yes No D:\IBMINST\RSP\REMOTE Keine aktiven Clients vorhanden. |
Der Server scheint soweit zu funktionieren, zur Sicherheit testen, ob ein Zugriff auf den Server möglich ist.
Config.sys um die Requesterkomponente ergänzen.
DEVICE=d:\tools\os2lan\SRVIFS.SYS
IFS=C:\toolss\os2lan\SRVIFSC.IFS * /T
Rechner neu starten, Service neu aktivieren, Requester auf lokaler Maschine testen.
[D:\tools\os2lan]srvattch.exe M: \\4HAOKHAR\CDROM
Du solltest nun ein Netzwerklaufwerk M: haben, das mit den CD-ROM identisch ist. Dies klappte, also kann man davon ausgehen, daß der Server arbeitet.
E-Mail 3 bei der der Groschen gefallen ist.
>> >Nach deinen CONFIG.SYS der Startdisks denke ich mal das du NETBEUI als Protokoll verwendest oder ? Ja, zusätzlich ist TCPBEUI installiert >>>Da muß ich doch mal einhaken , der Codeserver verwendet default den Lanadapter "0" .NETBEUI und TCPBEUI müssen ja jeweils als logische Adapter eingerichtet werden also z.B. LAN0 und LAN1 .Nun die möglicherweise wichtige Frage , IST TCPBEUI auf dem SERVER LAN0 ? BINGO! Hab die INI entsprechend angepaßt, dann klappte es als hätte es nie ein Problem gegeben ;-)) Hab nur nen Anpfiff vom Administrator gekriegt, da das Netz wohl etwas zugefahren war. |
Mögliche Lösungen in diesem Fall :
Den Server umkonfigurieren NETBEUI auf LAN0, TCPBEUI auf LAN1 (Neustart)
Neue Startdisks erzeugen, welche auf TCPBEUI als Protokoll ausgelegt sind.
Schnellster Weg: SERVICE.INI anpassen auf Verwendung von LAN1 für Codeserverdienst, bedarf nur der Änderung einer Zeile und Neustart des Codeserver.
2.1.8 MPTS kann nicht gestartet werden , es leuft angeblich schon
Das File \os2\install\ibmlanlk.log löschen , dann geht es wieder
Der Fehler tritt auf wenn man PEER Nachinstallieren will und sich der Laufwerksbuchstabe des CDROM inzwischen geändert hat . WARP speichert den Laufwerksbuchstaben von wo auf das Installiert wurde .
Ist das CDROM im Alphabet nach vorn gerutscht z.B. von G: auf F: so kann man es mit RESERVEDRIVELETTER=F in der Config.SYS wieder nach hinten schieben , geht auch um mehr als 2 oder 3 Laufwerksbuchstaben .
Ist das CDROM nach hinten gerutscht habt ihr wirklich ein Problem . Über SYSTEMKONFIGURATIEN / ENTFERNEN das gesammte MPTS und PEER entfernen und von CD dann neu Installieren lassen .
Alternativ kann man versuchen rauszufinden aus welcher Datei Warp das alte CDROM Laufwerk ausliest und dort die Laufwerksbezeichnung ändern .
Man kann auf jeden Fall die Zeit zum Starten des Requesters reduzieren.
In der PROTOCOL.INI NETBIOSTIMEOUT = 500 und NETBIOSRETRIES = 2 setzen. Wird der Rechner vorwiegend als CLIENT eingesetzt in der IBMLAN.INI bei SRVSERVICES = den Eintrag PEER entfernen und die Peer-Dienste nur bei Bedarf mit NET START PEER aktivieren. Alles andere, was das Peer angeht, findet sich in der IBMLAN. INI beschrieben. Der Aufwand, das auszutesten steht vermutlich in keinem Verhältnis zum Nutzen. Wer noch ein paar Tips hat, soll sie mir doch bitte schicken.
Noch ein Hinweis zur Geschwindigkeit im Netz.
Es gibt jetzt drei mögliche Ursachen warum es nicht geht.
1. Es ist ein Fehler in der Peer-Konfiguration.
2. Ein Fehler auf Protokoll oder Netzwerktreiber-Ebene.
3. Fehler in der Hardware.
Um 1 auszuschließen gibt es einen recht einfachen Weg. Installiere das TCP/IP Paket und das TCP/IP Protokoll zu dem LAN-Adapter dazu. Dasselbe auf dem anderen Rechner, TCP/IP konfigurieren, was in einer guten Minute erledigt ist. Nun mit PING.EXE einen Ping auf die eigene Adresse, geht das, so scheint TCP/IP korrekt zu laufen. Nun einen Ping auf die IP des 2. Rechners. War der Ping erfolgreich, ist die Netzwerkkarte und der Treiber O.K. Der Fehler liegt demnach in den Werten für Netbios oder in der Protocol.ini (PEER) begraben.