STARTMODE="manual" funktioniert nicht immer
Ich stelle fest, daß STARTMODE="manual" für das Einwahl- Device nicht bei jedem PC (Suse 8.2, 2.4.26) zu dem gewünschten Ergebnis führt, daß das Device beim booten abgeschaltet ist. Ich habe einen Kunden, bei dem ist das ippp1 nach einem Neustart immer "up", also so wie wenn STARTMODE="onboot" konfiguriert wäre. isdnctrl list ippp1: =================== Current setup of interface 'ippp1': EAZ/MSN: xxxxxxxx Phone number(s): Outgoing: Incoming: xxxxxxxx xxxxxxxxxx xxxxxxx Dial mode: manual Secure: on Callback: off Reject before Callback: on Callback-delay: 2 Dialmax: 1 Hangup-Timeout: 60 Incoming-Hangup: off ChargeHangup: on Charge-Units: 0 Charge-Interval: 0 Layer-2-Protocol: hdlc Layer-3-Protocol: trans Encapsulation: syncppp Slave Interface: None Slave delay: 10 Master Interface: None Pre-Bound to: Nothing PPP-Bound to: 1 Woran könnte das liegen? (ich habe überall standardmäßig den smpppd abgeschaltet und per mv smpppd smpppd_ auch vor einem ungewollten Start durch Yast geschützt) danke schonmal Ekkard
On Sun, May 01, 2005 at 01:45:46AM +0200, Ekkard Gerlach wrote:
Ich stelle fest, daß STARTMODE="manual" für das Einwahl- Device nicht bei jedem PC (Suse 8.2, 2.4.26) zu dem gewünschten Ergebnis führt, daß das Device beim booten abgeschaltet ist. Ich habe einen Kunden, bei dem ist das ippp1 nach einem Neustart immer "up", also so wie wenn STARTMODE="onboot" konfiguriert wäre.
Ist auch SuSEconfig gelaufen und welche ISDN HW ? Steht in /etc/sysconfig/network/ifcfg-ippp1 auch STARTMODE=manual drin ?
isdnctrl list ippp1: =================== Current setup of interface 'ippp1':
EAZ/MSN: xxxxxxxx Phone number(s): Outgoing: Incoming: xxxxxxxx xxxxxxxxxx xxxxxxx Dial mode: manual Secure: on Callback: off Reject before Callback: on Callback-delay: 2 Dialmax: 1 Hangup-Timeout: 60 Incoming-Hangup: off ChargeHangup: on Charge-Units: 0 Charge-Interval: 0 Layer-2-Protocol: hdlc Layer-3-Protocol: trans Encapsulation: syncppp Slave Interface: None Slave delay: 10 Master Interface: None Pre-Bound to: Nothing PPP-Bound to: 1
Woran könnte das liegen?
(ich habe überall standardmäßig den smpppd abgeschaltet und per mv smpppd smpppd_ auch vor einem ungewollten Start durch Yast geschützt)
danke schonmal Ekkard
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
-- Karsten Keil SuSE Labs ISDN development
* Karsten Keil schrieb:
On Sun, May 01, 2005 at 01:45:46AM +0200, Ekkard Gerlach wrote:
Ich stelle fest, daß STARTMODE="manual" für das Einwahl- Device nicht bei jedem PC (Suse 8.2, 2.4.26) zu dem gewünschten Ergebnis führt, daß das Device beim booten abgeschaltet ist. Ich habe einen Kunden, bei dem ist das ippp1 nach einem Neustart immer "up", also so wie wenn STARTMODE="onboot" konfiguriert wäre.
Ist auch SuSEconfig gelaufen und welche ISDN HW ? Steht in /etc/sysconfig/network/ifcfg-ippp1 auch STARTMODE=manual drin ?
JA! Das device ist definitiv immer "up" nach dem booten. Bei mir hier, bei meiner Suse 8.2 funktioniert es aber wie von Dir beschrieben: ein manual startet das ippp1 (Einwahldevice) nicht automagisch beim booten, sondern erst wenn ich ein ifup ippp1 mache: # # DO NOT EDIT THIS FILE !!! # autogenerated by SuSEconfig.isdn from /etc/sysconfig/isdn/cfg-net1 # edit /etc/sysconfig/isdn/cfg-net1 instead and run # SuSEconfig --module isdn # STARTMODE="manual" IPADDR="192.168.91.1" PTPADDR="192.168.91.200" DEFAULTROUTE="no" FIREWALL="no" MSN="xxxxxxxxx" DIALMODE="manual" DIALPREFIX="" DIALMAX="" REMOTE_OUT="" REMOTE_IN="xxxxxxxx xxxxxxxxxx xxxxxxxxx" PROVIDER="pc_dialin" SECURE="on" CHARGEHUP="on" CALLBACK="off" CBDELAY="" CBHUP="" IHUP="" VERBOSE_LEVEL="" SLAVES="ippp7" MULTILINK="yes" SLAVEMSN="" SLAVE_IN="" SLAVE_OUT="" LAYER2="hdlc" LAYER3="trans" ENCAP="syncppp" IP_RESEND="" IP_RESEND_PARAMETER="" SMPPPD_IGNORE="" DYNAMICIP="no" IPPPD_OPTIONS="+pap -chap debug proxyarp" ASKPASSWORD="" MTU="" MRU="" RUN_POLL_TCPIP="" Habe mal in /var/log/messages vom letzten Boot reingesehen: May 3 06:17:59 pserver ipppd: info: no PAP secret entry for this user! May 3 06:17:59 pserver ipppd[2744]: Found 2 devices: , May 3 06:17:59 pserver ipppd[2745]: ipppd i2.2.12 (isdn4linux version of pppd by MH) started May 3 06:17:59 pserver ipppd[2745]: init_unit: 0 May 3 06:17:59 pserver kernel: ippp, open, slot: 3, minor: 1, state: 0000 May 3 06:17:59 pserver kernel: ippp_ccp: allocated reset data structure d4518000 May 3 06:17:59 pserver ipppd[2745]: Connect[0]: /dev/ippp1, fd: 7 May 3 06:17:59 pserver ipppd[2745]: init_unit: 1 May 3 06:17:59 pserver kernel: ippp, open, slot: 4, minor: 7, state: 0000 May 3 06:17:59 pserver kernel: ippp_ccp: allocated reset data structure d4519800 May 3 06:17:59 pserver ipppd[2745]: Connect[1]: /dev/ippp7, fd: 8 Was'n das? ippp7? -> nachgesehen in /etc/sysconfig/network/ifcfg-ippp1: Tasächlich: SLAVES="ippp7" MULTILINK="yes" Ein cfg-net7 gibts nicht, dafür aber unter isdnctrl list ippp7 etwas: Current setup of interface 'ippp7': EAZ/MSN: xxxxxxx Phone number(s): Outgoing: Incoming: xxxxxxxxxxx xxxxxx xxxxxx Dial mode: auto <<<<<=== !!!!!!!!!!!! AUTO !!!! Secure: on Callback: off Reject before Callback: on Callback-delay: 2 Dialmax: 1 Hangup-Timeout: 60 Incoming-Hangup: off ChargeHangup: on Charge-Units: 0 Charge-Interval: 0 Layer-2-Protocol: hdlc Layer-3-Protocol: trans Encapsulation: syncppp Slave Interface: None Slave delay: 10 Master Interface: ippp1 Pre-Bound to: Nothing PPP-Bound to: 7 Macht das ifup-Skript also ein freies ipppX ausfindig und startet dort den Slave? (BTW: ich habe noch nie den Slave gebraucht, ich schalte den gleich ab.) Scheinbar ist bei Multilink das Device immer "up". (Bug? Feature?) Also werde ich mal SLAVES="ippp7" MULTILINK="yes" aus cfg-net1 herausnehmen, SuSEconfig --module isdn laufen lassen. Dann sehen wir mal, wenn der PC meines Kunden das nächste Mal gebootet hat. Gruss Ekkard
Lösung! In der crontab hatte ich ein ifup ippp untergebracht (weil unter Suse 8.2 bei einer VNC-Fernwartungssitzung per ISDN immer die Verbindung abgeschaltet wird, wenn die Sitzung herunterfährt) und daran hatte ich mich nicht mehr erinnert. Also: "manual" funktioniert schon korrekt. Danke an Karsten Ekkard
participants (2)
-
Ekkard Gerlach -
Karsten Keil