folgendes Problem. Ich nutze Suse6.0 (2.0.36) als Internet-Gateway und
die Uni als Provider. Nun habe ich seit dem Wochenende leichte! Probleme
bei der Einwahl (messages bringt mir einen HiSax, ch0 cause E0010, was
meiner Meinung nach [man isdn_cause] eher an meiner Einstellung liegt,
aber nach 'genauer' Prüfung - nichts Softwaremässiges verändert - nicht
standhält). Die Einwahl klappt dann aber doch manchmal, er bringt mir
aber für die anderen Verbindung auch eine Zeit > 0 (also Gebühren).
Hat erstens jemand auch schon dieses Fehlerbild gesehen? und weiss
möglicherweise eine Lösung.
Und zweitens gibt es eine Möglichkeit dem ippp0 nach fehlerhafter
Einwahl zu sagen, dass er es das nächste mal über einen anderen Provider
probieren soll (dynamische Änderung von i4l_options.rc.config oder
ip-up/down ? ). Das wäre dann ja auch einsetzbar als eine Art least cost
routing!
Vielleicht kann mich ja jemand auf die richtige Spur setzen
cu Heiko
bash-2.03# isdnctrl list all
Current setup of interface 'ippp0':
EAZ/MSN: 992540
Phone number(s):
Outgoing: 063719040
Incoming:
Dial mode: auto
Secure: on
Callback: off
Reject before Callback: on
Callback-delay: 2
Dialmax: 2
Hangup-Timeout: 24
Incoming-Hangup: off
ChargeHangup: off
Charge-Units: 0
Charge-Interval: 0
Layer-2-Protocol: hdlc
Layer-3-Protocol: trans
Encapsulation: syncppp
Slave Interface: None
Slave delay: 10
Slave trigger: 6000 cps
Master Interface: None
Pre-Bound to: Nothing
PPP-Bound to: 0
eb 7 16:47:51 Yakumo kernel: ISDN subsystem Rev:
1.91/1.79/1.95/1.58/1.17/1.3 loaded
Feb 7 16:47:51 Yakumo kernel: HiSax: Linux Driver for passive ISDN
cards
Feb 7 16:47:51 Yakumo kernel: HiSax: Version 3.3c (module)
Feb 7 16:47:51 Yakumo kernel: HiSax: Layer1 Revision 2.36
Feb 7 16:47:51 Yakumo kernel: HiSax: Layer2 Revision 2.20
Feb 7 16:47:51 Yakumo kernel: HiSax: TeiMgr Revision 2.13
Feb 7 16:47:51 Yakumo kernel: HiSax: Layer3 Revision 2.10
Feb 7 16:47:51 Yakumo kernel: HiSax: LinkLayer Revision 2.39
Feb 7 16:47:51 Yakumo kernel: HiSax: Approval certification valid
Feb 7 16:47:51 Yakumo kernel: HiSax: Approved with ELSA Quickstep
series cards
Feb 7 16:47:51 Yakumo kernel: HiSax: Approval registration numbers:
Feb 7 16:47:51 Yakumo kernel: HiSax: German D133361J CETECOM ICT
Services GmbH
Feb 7 16:47:51 Yakumo kernel: HiSax: EU (D133362J) CETECOM ICT Services
GmbH
Feb 7 16:47:51 Yakumo kernel: HiSax: Approved with Eicon Technology
Diva 2.01 PCI cards
Feb 7 16:47:51 Yakumo kernel: HiSax: Total 1 card defined
Feb 7 16:47:51 Yakumo kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
Feb 7 16:47:51 Yakumo kernel: HiSax: HFC-S driver Rev. 1.5
Feb 7 16:47:51 Yakumo kernel: HFCS: defined at 0x580 IRQ 4 HZ 100
Feb 7 16:47:51 Yakumo kernel: HFCS: resetting card
Feb 7 16:47:51 Yakumo kernel: Teles 16.3c: IRQ 4 count 0
Feb 7 16:47:51 Yakumo kernel: HiSax: WaitNoBusy timeout
Feb 7 16:47:51 Yakumo last message repeated 2 times
Feb 7 16:47:51 Yakumo kernel: Teles 16.3c: IRQ 4 count 1
Feb 7 16:47:51 Yakumo kernel: HiSax: DSS1 Rev. 2.20
Feb 7 16:47:51 Yakumo kernel: HiSax: 2 channels added
Feb 7 16:47:51 Yakumo kernel: HiSax: MAX_WAITING_CALLS added
Feb 7 16:47:51 Yakumo kernel: HiSax: debugging flags card 1 set to 4
Feb 7 16:47:51 Yakumo kernel: isdn: Verbose-Level is 3
Feb 7 16:49:17 Yakumo modprobe: modprobe: Can't locate module
char-major-15
Feb 7 16:56:07 Yakumo kernel: OPEN: 192.168.111.113 -> 195.178.0.23
UDP, port: 1024 -> 53
Feb 7 16:56:07 Yakumo kernel: ippp0: dialing 1 063719040...
Feb 7 16:56:14 Yakumo kernel: isdn: HiSax,ch0 cause: E001B
Feb 7 16:56:15 Yakumo kernel: ippp0: dialing 2 063719040...
Feb 7 16:56:22 Yakumo kernel: isdn: HiSax,ch0 cause: E001B
Feb 7 16:56:23 Yakumo kernel: isdn_net: local hangup ippp0
Feb 7 16:56:23 Yakumo kernel: ippp0: Chargesum is 0
Helge
Heiko Teichmann schrieb:
Das Problem hat sich mittlerweile erledigt, es lag eine
Fehlkonfiguration des Einlog-Servers an der UNI vor.
Aber eine Anwort zu der anderen Frage würde mich schon noch
interessieren. Also wenn jemand eine Idee hat. Bin für alle Tips
dankbar.
> Und zweitens gibt es eine Möglichkeit dem ippp0 nach fehlerhafter
> Einwahl zu sagen, dass er es das nächste mal über einen anderen Provider
> probieren soll (dynamische Änderung von i4l_options.rc.config oder
> ip-up/down ? ). Das wäre dann ja auch einsetzbar als eine Art least cost
> routing!
cu Heiko
In der iX 01/2000 wird genau das beschrieben.
(ftp.heise.de/pub/ix/ix_listings/2000_01.tar.gz) Allerdings ist mir auch
voellig unklar, wie das mit Passwort und Loginname klappen soll. Ich
befuerchte, dass das von der iX nur funktioniert, weil die meisten
Call-by-Call Internet Provider beliebige Loginnamen und Passwoerter
erlauben (z.B. Mobilcom). Das angegebene Listings kann ich nicht
ausprobieren, da ich Call-by-Call nicht nutzen kann.
Loginame und Passwort entnimmt der ipppd der Datei /etc/ppp/pap-secrets.
Hier koennen fuer verschiedene Logins die noetigen Daten eingetragen
werden. Die Angabe name oder user in /etc/ppp/ioptions bestimmt den
Loginnamen. Diese
Datei wird aber nur beim Starten des ipppd gelesen. Im Betrieb kann man
so also nicht die Daten wechseln, ausser mit init 1 - init 2, eine
unschoene Behelfsloesung. Bei mir ist das Problem sogar noch groesser,
da ich bei zwei Providern jeweils den gleichen Loginnamen jowagner habe.
Laut Dokumentation (ISDN HowTo www.franken.de/users/klaus/DE-ISDN-HOWTO/
und
PPP-HowTo ...) ist der Parameter remotehostname auch keine Hilfe, da
Provider normalerweise hinter einer Einwahlnummer mehrere Rechner mit
verschiendenen Namen haben.
Weiss jemand mehr? Irgendwelche Ideen?
Joachim Wagner
Helge Baurmann wrote:
>
> Mit
> isdnctrl addphone ippp? out Telefonnummer
> kann man mehrere Nummern angeben. Er wählt dann immer die letzte eingegebene
> zuerst. [gerade entdeckt :-) ]
> Wie das mit Password und Namen als dynamisch ist weiß ich erstmal nicht.
>
> Helge
>
> Heiko Teichmann schrieb:
>
> > Hallo Wissende,
> >
[...]
> > Und zweitens gibt es eine Möglichkeit dem ippp0 nach fehlerhafter
> > Einwahl zu sagen, dass er es das nächste mal über einen anderen Provider
> > probieren soll (dynamische Änderung von i4l_options.rc.config oder
> > ip-up/down ? ). Das wäre dann ja auch einsetzbar als eine Art least cost
> > routing!
> >