On Fri, Mar 14, 2003 at 06:18:47PM +0100, Wolfgang Hinsch wrote:
Am Don, 2003-03-13 um 15.43 schrieb Karsten Keil:
On Wed, Mar 12, 2003 at 02:29:32PM +0100, Wolfgang Hinsch wrote:
Hallo Liste,
-SuSE 8.1 / Fritz V.2pci / hisax / Yast
ich habe einen Rechner mit einer Fritz-Card, der soll mit verschiedenen Partnern Daten austauschen. Das funktioniert auch soweit (meistens), aber jetzt wollte ich etwas ändern. Ich habe eine Verbindung gelöscht (mit Yast), wobei erst sich der Provider nicht löschen liess, sondern nur die Schnittstelle, yast beenden, starten, provider löschen. Dabei habe ich mich irgendwo verklickt und bin auf der falschen Schnittstelle gelandet. Das hatte ich gemerkt und habe den Vorgang abgebrochen.
Die Situation ist jetzt die, dass der Rechner korrekt hinauswählt, aber bei bei der Einwahl eines Partners die ippp-Nummern vertauscht (und damit die IP falsch setzt) und sofort versucht, mit der korrekten ippp-Nummer zurückzurufen.
Es gibt keine direkte Zuordnung cfg-netX -> ipppX und auch die userdaten sind eigentlich unabhaengig von ipppX.
Eventuell ist jetzt eine route falsch gesetzt, ueberpruefe doch mal
/etc/sysconfig/network/routes und /etc/sysconfig/network/ifroute-ipppX
Erst mal vielen Dank an Karsten für die Reaktion.
/etc/sysconfig/network/ifroute-ipppX gibt es bei mir nicht, nur ifcfg-ippp[0-5]. Die Datei network/routes ist im Moment noch nicht betroffen, da ich direkt mit den IP-Nummern der Fritzkarten arbeite. Routing führe ich erst dann ein, wenn die Punkt-zu-Punkt-Verbindung läuft.
Nebenbei bemerkt, habe ich ein Yast-Problem mit der msn entdeckt. Im Rechner B (s.u.) war die MSN verkehrt gesetzt (richtige Nr, aber mit Vorwahl). Das habe ich per Yast korrigiert (auch im Menü für die ISDN-Karte), aber später festgestellt, dass Yast vergisst, die Nummer in ifcfg-ippp0 zu korrigieren. Im Yast-Menü erscheint die richtige MSN, aber im File bleibt die Vorwahl auch bei mehrfachem Yast-Aufruf. Auf diesem Rechner B gibt es nur eine ippp0-Schnittstelle.
Also YaST selbst aendert nur /etc/sysconfig/isdn/cfg-net* und /etc/sysconfig/network/providers/* und ruft anschliesend SuSEconfig --module isdn auf, das die Aenderungen in die /etc/sysconfig/network/ifcfg-ippp* uebertraegt. Scheinbar ist SuSEconfig.isdn irgendwie kaputt gegangen.
Der Cisco hat keine MSN, da Leihgabe des Museums für Datenübertragungen im Altertum Der Cisco wird mit einer anderen MSN angewählt als B. Diese Anwahl protokolliert der isdnlog von B korrekt mit und lehnt die Verbindung korrekt ab.
Rechner A hat noch die Macke, dass bei einer aktiv von ihm aufgebauten ISDN-Verbindung immer erst der Wachhund (Watchdog) den Treiber beissen muss, damit ein ping durchkommt.
Bekanntes Problem, Kernelupdate notwendig.
ping A -> B funktioniert einwandfrei (bis auf 30 Sek, s.o.) ping A -> C funktioniert einwandfrei "" ping C -> A funktioniert super. ping B -> A macht die Probleme:
A meldet einen Einwahlversuch mit der korrekten Nummer von B, allerdings mit der Einschränkung, dass er behauptet, B stünde in Äthiopien. Ursache dafür ist offensichtlich, das das Präfix 0 beim Herauswählen korrekt
Das ist reines logging und hat nichts mit der Funktion zu tun und kann durch spezielle Einstellungen in der isdnlog Konfiguration behoben werden. Da es bei fast jeder TK Anlage unterschiedliche Konfigurationen gibt, wie die Nummern durchgereicht werden, ist es nicht allgemeingültig lösbar.
gesetzt wird, bei der Hereinwahl jedoch nicht aus der Einwahlnummer entfernt wird. A akzeptiert diesen Anruf und gibt die Meldung "ippp3 connected". Hier ist das Problem. B liegt auf ippp2.
Der Rest ist falsch, aber folgerichtig. A hat ein Paket, das zurück nach B soll und eine (für ihn scheinbare) Verbindung nach C. Also versucht er B anzuwählen, scheitert aber natürlich an der besetzten Leitung.
Im Falle C behauptet A Standort Rumänien (s.o. Äthiopien), aber sonst alles klar.
Zur Zeit bekommt A auf einer freien Partition eine Neuinstallation. Damit ist der Wachhund gebändigt, und die Verbindung zu B läuft in beiden Richtungen einwandfrei (Äthiopien). Aber es handelt sich um den exakt gleichen Softwarestand (8.1 gepatcht bis Ende Januar). Deshalb würde ich das ABC-Problem gerne lösen, da ich sonst wahrscheinlich irgendwann wieder davor stehe.
Logs und konf-Dateien kann ich schicken, wollte jetzt aber die Liste nicht zu sehr belasten.
Schick mir die config Dateien direkt und auch die Ausgabe von isdnctrl list all sowie das entsprechende log. Interessant ist auch ein rpm -V i4l-base -- Karsten Keil SuSE Labs ISDN development