ISDN-Zugang unter 8.1 will nicht so recht
Hallo Liste, mein Problem ging vor ein paar Wochen hier über die Liste, brach aber genau da, ab wo der Problemlösungsansatz m.E. anfing: ich gehe mit kinternet ins Net, sehe mir das Protokoll an und es tut sich nix. Pinge ich dann www.suse.de an in einem Befehlsfenster wird das kinternet-Fensterchen rot. Gleichzeitig sagt Protokoll: 'we are connected', um exakt 9 Sekunden später zu sagen 'we are disconnected'. kinternet-Fensterchen wird wieder grün. Daraufhin habe ich in den Einstellungen der Schnittstelle die Option 'Charge Hub' deaktiviert. Keine nachhaltige Wirkung! Habe dann mal wie damals empfohlen mir die /var/log/messages herauskopiert, angeguckt, und mir dann gesagt: Junge, Du bist zu blöd, das zu interpretieren. Deshalb hiermal ein Auszug aus den messages, vielleicht hat ja einer von euch (war übrigens Sven's Idee mit den messages) eine Idee, an welcher Schraube ich drehen muß. Mir reicht auch der Hinweis auf eine Bedienungsanleitung für diese Schraube ;-) Jun 7 16:02:03 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:12 zeus kernel: isdn_net: local hangup ippp0 Jun 7 16:02:12 zeus kernel: ippp0: Chargesum is 0 Jun 7 16:02:22 zeus kernel: NETDEV WATCHDOG: ippp0: transmit timed out Jun 7 16:02:22 zeus kernel: isdn_tx_timeout dev ippp0 dialstate 0 Jun 7 16:02:22 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:22 zeus kernel: capidrv-1: dail ch=0,"12345,7,0,67891" in use (plci=0x101) Jun 7 16:02:31 zeus kernel: isdn_net: local hangup ippp0 Jun 7 16:02:31 zeus kernel: ippp0: Chargesum is 0 Jun 7 16:03:02 zeus kernel: NETDEV WATCHDOG: ippp0: transmit timed out Jun 7 16:03:02 zeus kernel: isdn_tx_timeout dev ippp0 dialstate 0 Jun 7 16:03:02 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:03:02 zeus kernel: capidrv-1: dail ch=0,"12345,7,0,67891" in use (plci=0x101) Jun 7 16:03:11 zeus kernel: isdn_net: local hangup ippp0 Jun 7 16:03:11 zeus kernel: ippp0: Chargesum is 0 Jun 7 16:03:42 zeus kernel: NETDEV WATCHDOG: ippp0: transmit timed out Jun 7 16:03:42 zeus kernel: isdn_tx_timeout dev ippp0 dialstate 0 Anmerkung: 12345 ist die Einwahlnummer des Providers, 67891 die von mir angenommene eigene MSN, die ich auch auf 0 stellen können müßte. Für Tips und Anregungen jetzt schon dankbar, und ein schönes Pfingstwochenende wünschend, Martin -- Microsoft isn't the answer. Microsoft is the question, and the answer is no. -- Grant Edwards
On Sat, Jun 07, 2003 at 07:57:16PM +0200, Martin Küppers wrote:
Hallo Liste,
mein Problem ging vor ein paar Wochen hier über die Liste, brach aber genau da, ab wo der Problemlösungsansatz m.E. anfing: ich gehe mit kinternet ins Net, sehe mir das Protokoll an und es tut sich nix. Pinge ich dann www.suse.de an in einem Befehlsfenster wird das kinternet-Fensterchen rot. Gleichzeitig sagt Protokoll: 'we are connected', um exakt 9 Sekunden später zu sagen 'we are ... disconnected'. kinternet-Fensterchen wird wieder grün. Daraufhin habe ich in den Einstellungen der Schnittstelle die Option 'Charge Hub' deaktiviert. Keine nachhaltige Wirkung! Habe dann mal
nein das bringt nichts.
wie damals empfohlen mir die /var/log/messages herauskopiert, angeguckt, und mir dann gesagt: Junge, Du bist zu blöd, das zu interpretieren. Deshalb hiermal ein Auszug aus den messages, vielleicht hat ja einer von euch (war übrigens Sven's Idee mit den messages) eine Idee, an welcher Schraube ich drehen muß. Mir reicht auch der Hinweis auf eine Bedienungsanleitung für diese Schraube ;-)
Jun 7 16:02:03 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:12 zeus kernel: isdn_net: local hangup ippp0
Das sieht nach HW Problemem aus, bitte mal die Ausgabe von cat /proc/interrupts vor einem Versuch und danach. Auch sollte mal in /etc/ppp/ioptions debug Aktiviert werden (# vor debug entfernen) Ein paar Angaben zur HW waeren auch nicht schlecht. -- Karsten Keil SuSE Labs ISDN development
*** Martin Küppers (MartinKueppers@t-online.de) schrieb in suse-isdn am Jun...:
[...] Jun 7 16:02:22 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:22 zeus kernel: capidrv-1: dail ch=0,"12345,7,0,67891" in use (plci=0x101) Jun 7 16:02:31 zeus kernel: isdn_net: local hangup ippp0 Jun 7 16:02:31 zeus kernel: ippp0: Chargesum is 0 Jun 7 16:03:02 zeus kernel: NETDEV WATCHDOG: ippp0: transmit timed out [... obiges mehrmals wiederholt ...]
Für Tips und Anregungen jetzt schon dankbar,
In aller Regel steht Grund für etwas nicht funktionierendes wortwörtlich im Log; so auch hier: Du bekommst keine Verbindung. Und zwar nicht, weil Deine Gegenseite besetzt wäre, sondern weil schlicht und einfach nichts passiert ("transmit timed out"). Es kommt ganz offensichtlich noch nichtmal eine ISDN-Verbindung zustande. Kabel gebrochen? Flasche Nummer? Etc? MfG Henning Hucke -- If you are honest because honesty is the best policy, your honesty is corrupt.
Am Sonntag, 8. Juni 2003 08:40 schrieb Henning Hucke:
Kabel gebrochen? Flasche Nummer? Etc?
Oder die Gegenseite braucht zu lang, um zu reagieren. Kommt hin und wieder bei Freenet vor, wobei das Problem bei unterschiedlichen Zugangsknoten unterschiedlich stark ausgeprägt ist. Bei einigen passiert es fast nie, bei anderen fast immer. Leider kann man den Timeoutwert wohl nicht konfigurieren. Gruß Markus
Am Samstag, 7. Juni 2003 21:32 schrieb Karsten Keil:
Jun 7 16:02:03 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:12 zeus kernel: isdn_net: local hangup ippp0
Das sieht nach HW Problemem aus, bitte mal die Ausgabe von
cat /proc/interrupts vor einem Versuch und danach.
Hallo Karsten, vorher: CPU0 0: 135259 XT-PIC timer 1: 816 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC fcclassic 8: 2 XT-PIC rtc 10: 4 XT-PIC eth0 11: 12972 XT-PIC acpi, aic7xxx, usb-uhci, usb-uhci 12: 54994 XT-PIC PS/2 Mouse NMI: 0 LOC: 0 ERR: 0 MIS: 0 nachher: CPU0 0: 165088 XT-PIC timer 1: 1128 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC fcclassic 8: 2 XT-PIC rtc 10: 4 XT-PIC eth0 11: 14911 XT-PIC acpi, aic7xxx, usb-uhci, usb-uhci 12: 63146 XT-PIC PS/2 Mouse NMI: 0 LOC: 0 ERR: 0 MIS: 0
Auch sollte mal in /etc/ppp/ioptions debug Aktiviert werden (# vor debug entfernen)
erledigt, bin aber leider noch nicht dazu gekommen, mir die logs nochmals anzusehen :-(
Ein paar Angaben zur HW waeren auch nicht schlecht.
Mainboard: K7V8363 KINETIZ 7 B/E Athlon ~900MHz, 256 RAM 2 HDDs IBM DYS-T 18350N SCSI DiskDevice 17 MB Adaptec AIC 7892 Ultra 160/m PCI-SCSI-Karte (11) ATI RAGE FURY Pro/Xpert 2000 Pro (11) AVM ISDN-Controller FRITZ!Card Classic ISA (7) TEAC CD-Rom CD-5325 SCSI D-LINK DFE-530TX PCI Fast Ethernet Adapter (Rev A)(11) Angaben sind aus dem MS Gerätemanager, Zahlen in Klammern die IRQs. Auf hda liegt Windows 2000 Server, Suse 8.1 auf hdb, an den Einstellungen zum Rechner insb. zur SCSI-Card habe ich noch nichts vorgenommen, da ich ihn erst kürzlich vom Vorgänger übernommen habe. Ziel ist der Aufbau eines kleinen Netzwerkes für und mit einer 11. Klasse parallel zum Windows-System des Kollegen Admin! Hoffe, die Angaben sind verwertbar, vorab Danke Gruß Martin -- Microsoft isn't the answer. Microsoft is the question, and the answer is no. -- Grant Edwards
Am Sonntag, 8. Juni 2003 08:40 schrieb Henning Hucke:
Jun 7 16:02:22 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:22 zeus kernel: capidrv-1: dail ch=0,"12345,7,0,67891" in use (plci=0x101) Jun 7 16:02:31 zeus kernel: isdn_net: local hangup ippp0 Jun 7 16:02:31 zeus kernel: ippp0: Chargesum is 0 Jun 7 16:03:02 zeus kernel: NETDEV WATCHDOG: ippp0: transmit timed out [... obiges mehrmals wiederholt ...]
Für Tips und Anregungen jetzt schon dankbar,
In aller Regel steht Grund für etwas nicht funktionierendes wortwörtlich im Log; so auch hier: Du bekommst keine Verbindung. Und zwar nicht, weil Deine Gegenseite besetzt wäre, sondern weil schlicht und einfach nichts passiert ("transmit timed out"). Es kommt ganz offensichtlich noch nichtmal eine ISDN-Verbindung zustande.
Kabel gebrochen? Flasche Nummer? Etc?
Hallo Henning, unter Win 2000 läuft es aber ohne Probs, 12345 dürfte also richtig sein. 67891 (MSN) ist möglicherweise nicht korrekt. Schau mir das mal an, wenn der Chef wieder da ist. Gruß Martin -- woody hanging? -> apt-get install viagra
*** Martin Küppers (MartinKueppers@t-online.de) schrieb in suse-isdn Heute: ((Bitte kein TUFO!))
[...]
Kabel gebrochen? Flasche Nummer? Etc?
Hallo Henning,
unter Win 2000 läuft es aber ohne Probs, 12345 dürfte also richtig sein. 67891 (MSN) ist möglicherweise nicht korrekt. Schau mir das mal an, wenn der Chef wieder da ist.
Wenn es unter Win funktioniert, ist es sicherlich kein gebrochenes Kabel. Eine falsch eingestellte MSN könnte bei einigen Telefonanlagen die beschriebenen Schwierigkeiten bereiten. Eine andere Sache ist die Amtsholung. Ich würde mir an Deine Stelle mal die Einstellungen des "Standorts" unter Windoof anschauen. Wenn dort eine Amtsholungsvorwahl eingetragen ist, gehört diese unter Linux latür- lich noch vor die Anwahlnummer... MfG Henning Hucke -- There are no great men, only great challenges that ordinary men are forced by circumstances to meet. -- Admiral William Halsey
On Mon, Jun 09, 2003 at 09:33:12AM +0200, Martin Küppers wrote:
Am Samstag, 7. Juni 2003 21:32 schrieb Karsten Keil:
Jun 7 16:02:03 zeus kernel: ippp0: dialing 1 12345... Jun 7 16:02:12 zeus kernel: isdn_net: local hangup ippp0
Das sieht nach HW Problemem aus, bitte mal die Ausgabe von
cat /proc/interrupts vor einem Versuch und danach.
Hallo Karsten,
vorher: CPU0 0: 135259 XT-PIC timer 1: 816 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC fcclassic 8: 2 XT-PIC rtc 10: 4 XT-PIC eth0 11: 12972 XT-PIC acpi, aic7xxx, usb-uhci, usb-uhci 12: 54994 XT-PIC PS/2 Mouse NMI: 0 LOC: 0 ERR: 0 MIS: 0
nachher: CPU0 0: 165088 XT-PIC timer 1: 1128 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC fcclassic 8: 2 XT-PIC rtc 10: 4 XT-PIC eth0 11: 14911 XT-PIC acpi, aic7xxx, usb-uhci, usb-uhci 12: 63146 XT-PIC PS/2 Mouse NMI: 0 LOC: 0 ERR: 0 MIS: 0
Aha, das bedeutet das der IRQ 5 nicht auf den ISA Slot geroutet ist und somit der Treiber keine IRQs bekommt, das deckt sich mit den anderen LOGs. Da ja Win funktioniert, schau mal in die Win Resourcen welcher IRQ dort verwendet wird und stell den ein (YaST). Falls das in Win auch IRQ 5 ist schau mal ins BIOS Setup, ob Du den IRQ fuer legacy ISA (nicht PnP ISA) reservieren kannst. ...
Mainboard: K7V8363 KINETIZ 7 B/E Athlon ~900MHz, 256 RAM 2 HDDs IBM DYS-T 18350N SCSI DiskDevice 17 MB Adaptec AIC 7892 Ultra 160/m PCI-SCSI-Karte (11) ATI RAGE FURY Pro/Xpert 2000 Pro (11) AVM ISDN-Controller FRITZ!Card Classic ISA (7)
Aha, 7 ist der IRQ, also in jedem Fall mal 7 probieren und gegebenfalls 7 auch nochmal im BIOS wie oben beschrieben setzen. Also in YAST -> network basis-> isdn-> Aendern -> Aendern (Oberes Fenster) IRQ auf einstellen. -- Karsten Keil SuSE Labs ISDN development
Am Montag, 9. Juni 2003 18:50 schrieb Karsten Keil: Hallo Karsten, sorry wegen der späten Rückmeldung, aber der Rechner steht 20 km entfernt und mails verschicke ich noch von zuhause aus.
Falls das in Win auch IRQ 5 ist schau mal ins BIOS Setup, ob Du den IRQ fuer legacy ISA (nicht PnP ISA) reservieren kannst. ... Aha, 7 ist der IRQ, also in jedem Fall mal 7 probieren und gegebenfalls 7 auch nochmal im BIOS wie oben beschrieben setzen.
Habe ich heute für 5 und 7 ausprobiert: ohne Erfolg. (5 deswegen, weil er laut Manual werkseitig zusammen mit I/O 300 voreingestellt ist. Vielleicht sollte ich mal auf eine andere I/O-Adresse umjumpern, aber welche??) Habe danach auch den Tip von Henning mit eingebaut: selbes Ergebnis. Muß wohl nochmal ins Archiv und zu Google... ;-) Gruß Martin *z.Zt. etwas ratlos*
On Wed, Jun 11, 2003 at 04:36:57PM +0200, Martin Küppers wrote:
Am Montag, 9. Juni 2003 18:50 schrieb Karsten Keil:
Hallo Karsten,
sorry wegen der späten Rückmeldung, aber der Rechner steht 20 km entfernt und mails verschicke ich noch von zuhause aus.
Falls das in Win auch IRQ 5 ist schau mal ins BIOS Setup, ob Du den IRQ fuer legacy ISA (nicht PnP ISA) reservieren kannst. ... Aha, 7 ist der IRQ, also in jedem Fall mal 7 probieren und gegebenfalls 7 auch nochmal im BIOS wie oben beschrieben setzen.
Habe ich heute für 5 und 7 ausprobiert: ohne Erfolg. (5 deswegen, weil er laut Manual werkseitig zusammen mit I/O 300 voreingestellt ist. Vielleicht sollte ich mal auf eine andere I/O-Adresse umjumpern, aber welche??)
Nein kein Grund, es gibt keine Zuordnung IRQ <-> IO Adresse. Default sagt hierbei nur das die AVM Software ohne das etwas eingestellt wird IRQ 5 verwendet. Das Problem ist immer das IRQ Routing auf dem Motherboard und dafuer ist bei Linux das BIOS zustaendig, das heist der entsprechende IRQ muss im BIOS des Rechners auf den ISA Bus geschalten sein und kein anderes Device darf diesen IRQ benutzen. (Im Gegensatz dazu tut Windows das IRQ Routing am BIOS vorbei beeinflussen). Wichtig bei allen Versuchen ist das Du /proc/interrupts beobachtest, nicht das Dein IRQ Problem durch ein anderes 2.Problem ueberdeckt wird. Wenn sich bei Verbindungsversuchen der entsprechende IRQ Zaehler erhoeht, ist das IRQ Problem gefixt. -- Karsten Keil SuSE Labs ISDN development
participants (4)
-
Henning Hucke -
Karsten Keil -
Markus Kohm -
MartinKueppers＠t-online.de