Re: eigener Einwahlpunkt
Ulf Volmer wrote:
On Fri, Aug 11, 2006 at 05:58:15PM +0200, Boris Andratzek wrote:
Ich habe einen PC mit Sarge und einer Fritz-PCI-Karte. Ich habe einen
Kernel 2.6.8-2-686 mit capi-support kompiliert. Jetzt muss ich doch
eigentlich 'nur' noch pppd konfigurieren und die Routen setzen, oder?
Jepp. In die passende peers die Optionen
plugin capiplugin.so
msn 123
sollte genügen.
Hallo Ulf,
zuerstmal ein Dankeschön!
Ich fürchte ich muss noch ein bisschen 'drunter' anfangen:
Ich habe in /etc/network/interfaces:
# Eintrag fuer ISDN-IN zwecks ISP
auto ppp0
iface ppp0 inet ppp
provider pppd_isdn-in capi20
Das Interface ppp0 kommt aber mitnichten automatisch up!
In meiner /etc/ppp/peers/pppd_isdn-in steht:
logfile /var/log/pppd_isdn-in.log
plugin capiplugin.so
msn 17
Die MSN 17 ist sicherlich wunderlich, aber mit größter
Wahrscheinlichkeit richtig, weil der Rechner hinter einer Tel.-Anlage
steht, die die echten MSNs in logische MSNs umsetzt. Klasse wäre naklar,
wenn ich irgendwo den Anruf sehen könnte, weiß aber nicht wo....
Starte ich nun das Interface mit ifup ppp0, dann bekomm ich in
/var/log/pppd_isdn-log:
Plugin capiplugin.so loaded.
capiplugin: $Revision: 1.36 $
capiconn: 1.10
capiplugin: phase serialconn.
controller 1: listen_change_state state=1 event=1 ????
controller 1: listen_change_state state=1 event=1 ????
controller 1: listen_change_state state=1 event=1 ????
controller 1: listen_change_state state=1 event=1 ????
controller 1: listen_change_state state=1 event=1 ????
controller 1: listen_change_state state=1 event=1 ????
capiplugin: waiting for incoming call ...
controller 1: listen_change_state state=2 event=4 ????
controller 1: listen_change_state state=2 event=4 ????
controller 1: listen_change_state state=2 event=4 ????
controller 1: listen_change_state state=2 event=4 ????
controller 1: listen_change_state state=2 event=4 ????
controller 1: listen_change_state state=2 event=4 ????
Nun rufe ich mit einem Telefon die 17 an und bekomme (nach ca 5
Sekunden) ein Busy-Zeichen.
Ich hatte schon eine erheblich umfangreichere
/etc/ppp/peers/pppd_isdn-in, mit der ist dann das ganze Netzwerk (inkl.
eth0) abgestürzt. Das passiert jetzt nicht mehr. Es spricht aber dafür,
dass der Anruf 'irgendwie' verarbeitet wird....
Muss nicht auch irgendwo erstmal stehen, dass der Anruf beantwortet
werden soll??
????
Gruß,
Boris
Reply to: