Defaultroute bei ISDN (SuSE 8.0)

[Baralis]

Hi !

Ich habe ein Problem mit meiner Defaultroute bei ISDN. Ich habe einen SuSE 8.0 Rechner, den ich auch zum Routing von DSL benutze.
Jetzt möchte ich gerne zusätzlich ISDN benutzten.
Es klappt auch alles wunderbar, nur die Defaultroute wird nicht gesetzt.
Ich muss sie jedesmal beim starten von ISDN per Hand nachtragen, obwohl
ich in die /etc/ppp/ip-up unter ip-up die Zeile

route add -net X.X.X.X netmask X.X.X.X gw $REMOTEIP dev ippp0

reingeschrieben habe.
Wird denn bei SuSE 8.0 ip-up nicht mehr benutzt ??
Ich habe auch schon mal ein paar echos in die ip-up geschrieben um zu gucken, ob irgendwas aufgerufen wird, aber ohne Erfolg.

Da ich zu faul bin, um jedesmal die defaultroute zu schreiben hoffe ich das mir jemand helfen kann und bedanke mich schon mal im voraus für jeden Tip :D

[LKH]

Hi,

wird durch den ADSL-Zugang nicht schon eine Defaultroute gesetzt? Zwei Defaultroutes gehen nicht. Und das, was im ip-up Skript steht setzt nur eine "normale" Route.

Aber vielleicht erklärst du mal kurz, was du überhaupt vorhast.

[Baralis]

Klar kein problem :D

Also ich kann mich per ISDN über eine 0800 Nummer in unser Firmennetz einwählen.
ich sage bei der Defaultroute dann bei ISDN z.B.

route add -net 192.150.0.0 netmask 255.255.0.0 gw (ISDN-REMOTEIP) dev ippp0

so das wenn ich z.B. 192.150.150.150 anspreche der über die gw ISDN gehen soll. Sobald ich eine andere IP anspreche, soll er halt über DSL rausgehen. Das klappt auch.
Nur leider hab ich das Problem, das ich jedesmal wenn ich ISDN starte der die route nicht automatisch einfügt.
Bei Linux 7.3 hatte ich das ja auch schon. Ich hab einfach nur in der ip-up die schöne Variable $REMOTEIP ausgenutzt, wo ich einfach nur sagen muss

route add -net 192.150.0.0 netmask 255.255.0.0 gw $REMOTEIP dev ippp0

und direkt die route mit der Dynamischen IP, die ippp0 zugewiesen bekommt, in meiner Routingtabelle schreibt. Das klappt aber bei SuSE 8.0 nicht. So muss ich immer gucken, welche IP ippp0 bekommen hat und diese als gw manuell in meine Routen hinzufügen, damit ich überhaupt was machen kann.
Jetzt frag ich mich nur, ob ich vielleicht irgendwas übersehen habe, oder ob das Problem auch schon andere kennen.

[Thomas Mitzkat]

wenn /etc/pppd/ip-up aufgerufen wird, wird die route neu gesetzt. da musst du ansetzten.


#!/bin/sh

# (C) 1997-2002 SuSE Linux AG, Nuernberg, Germany
# Klaus Franken <feedback@suse.de> 25.02.1998
# Remo Behn <feedback@suse.de> 18.07.1998
# Arvin Schnell <feedback@suse.de> 28.02.2002
# Send suggestions and comments to feedback@suse.de

BASENAME=${0##*/}
INTERFACE=$1
DEVICE=$2
SPEED=$3
LOCALIP=$4
REMOTEIP=$5
IPPARAM=$6

if [ -z "$REMOTEIP" ]; then
echo "Usage: $0 <INTERFACE> <DEVICE> <SPEED> <LOCALIP> <REMOTEIP>"
exit 1
fi

TERM=raw
export TERM

check_srv() {
RLVL=`/sbin/runlevel | sed 's/. //'`
test -L /etc/init.d/rc${RLVL}.d/S??$1 && return 0
return 1
}

start_firewall() {
case `uname -r` in
2.[345].*)
if check_srv SuSEfirewall2_setup; then
/sbin/SuSEfirewall2 start
else
if check_srv SuSEfirewall_setup; then
/sbin/SuSEfirewall start
fi
fi
;;
*)
if check_srv SuSEfirewall_setup; then
/sbin/SuSEfirewall start
fi
;;
esac
# KG: Probably not correct any more: Should check symlinks as well
test -x /sbin/SuSEpersonal-firewall && . /sbin/SuSEpersonal-firewall
}

# from here on output is logged by logger
case "$INTERFACE" in
ippp*)

if [ -f /etc/sysconfig/network/ifcfg-$INTERFACE ] ; then
. /etc/sysconfig/network/ifcfg-$INTERFACE
# should be deleted after DYNAMICDNS->USEPEERDNS migration
test -z "$USEPEERDNS" -a -n "$DYNAMICDNS" && USEPEERDNS=$DYNAMICDNS
else
echo "Device '$INTERFACE' has no sysconfig file";
exit 1
fi

case "$BASENAME" in
ip-up)
#
# Get the nameservers (works with ipppd option ms-get-dns):
#
# ----------------------------------------------------------------------------------
# setz doch im anschluss an und bringe deinen route befehl stattdessen rein
# ----------------------------------------------------------------------------------
# if [ "$USEPEERDNS" = "yes" -a -n "$MS_DNS1" ]; then
# /sbin/modify_resolvconf modify -s ipppd -e "$INTERFACE" \
# -p ipppd -f /etc/ppp/ip-up -n "$MS_DNS1 $MS_DNS2" -t - << EOT
# If you do not like the ipppd to change your nameserver
# settings remove the option USEPEERDNS for this connection
EOT
# fi

route add -net 192.150.0.0 netmask 255.255.0.0 gw $REMOTEIP dev $INTERFACE

# ip_resend hook
test "$IP_RESEND" = "yes" -a -x /usr/sbin/ip_resend_wakeup && \
/usr/sbin/ip_resend_wakeup -m $LOCALIP -o $INTERFACE

#
# SuSE Firewall script: If you installed and configured your firewall
# in /etc/sysconfig/firewall it will be started here:
#
test "$FIREWALL" = "yes" && start_firewall

#
# You may choose to use a default firewall script, configured for
# the standard dialup user(install package ipchains):
#
#test -x /etc/ppp/inet_chains.local && /etc/ppp/inet_chains.local "$@"

# maybe you want to start mail services:
# set follow variables in /etc/sysconfig/sendmail
# SENDMAIL_TYPE="yes"
# SENDMAIL_SMARTHOST="<ISP-mailserver>"
# SENDMAIL_ARGS="-bd -om"
# SENDMAIL_EXPENSIVE="yes"
# SENDMAIL_NOCANONIFY="yes"
#/usr/bin/fetchmail -a -v >>/var/log/fetchmail 2>&1 &
#/usr/sbin/sendmail -q &

# As an alternative to the commands above, you can use a seperate script,
# /etc/ppp/poll.tcpip. The default scripts as shipped is able to set the
# system clock using ntpdate (see the XNTPD_INITIAL_NTPDATE setting in
# /etc/sysconfig/xntp). It supports fetchmail with a system-wide
# /etc/fetchmailrc and can use UUCP to fetch mail over TCP/IP, provided
# that UUCP is configured properly. Last not least it also calls sendmail
# to send any queued mail. Uncomment the line below.
if test "$RUN_POLL_TCPIP" != "no" ; then
/etc/ppp/poll.tcpip | logger -p security.notice -t poll.tcpip > /dev/null &
fi

# call ip-up.local if it exists and is executable:
if test -x /etc/ppp/ip-up.local ; then
/etc/ppp/ip-up.local "$@" | logger -p security.notice -t ip-up.local > /dev/null &
fi
;;
ip-down)
#
# Restore the nameservers (got with ipppd option ms-get-dns):
#
if [ "$USEPEERDNS" = "yes" -a -n "$MS_DNS1" ]; then
/sbin/modify_resolvconf restore -s ipppd -e "$INTERFACE"
fi

# restart interface
LINK_OPT=""
test "$DYNAMICIP" = "yes" && LINK_OPT="$LINK_OPT dynamic on"
/sbin/ip address flush dev $INTERFACE
/sbin/ip link set $INTERFACE down
/sbin/ip link set $INTERFACE up $LINK_OPT
/sbin/ip address add dev $INTERFACE local $IPADDR peer $PTPADDR

# set routes from /etc/sysconfig/network/routes (only for dod)
if [ "$DIALMODE" = "auto" ] ; then
/etc/sysconfig/network/scripts/ifup-route $INTERFACE
fi

#
# SuSE Firewall script: If you installed and configured your firewall
# in /etc/sysconfig/firewall it will be started here:
#
test "$FIREWALL" = "yes" && start_firewall

# call ip-down.local if it exists and is executable:
if test -x /etc/ppp/ip-down.local ; then
/etc/ppp/ip-down.local "$@" | logger -p security.notice -t ip-down.local > /dev/null &
fi

# ip_resend hook
test "$IP_RESEND" = "yes" -a -x /usr/sbin/ip_resend && \
/usr/sbin/ip_resend -o $INTERFACE $IP_RESEND_PARAMETER
;;
*)
;;
esac
;;

ppp*)
# Analog-PPP, add commands as you need...
case "$BASENAME" in
ip-up)
#
# This code allows automatic configuration of your resolv.conf
# for peer supplied DNS addresses when using the `usepeerdns'
# option. Original resolv.conf is restored when ip-down is called
# by pppd when the link goes down.
#
if [ -n "$USEPEERDNS" -a -f /etc/ppp/resolv.conf ]; then
/sbin/modify_resolvconf modify -s pppd -p pppd -e "$INTERFACE" \
-f /etc/ppp/ip-up -n "$DNS1 $DNS2" -t - << EOT
If you do not want the pppd to change your nameserver settings
set AUTODNS=no in the config file for this provider in
/etc/sysconfig/network/providers/ and ensure that the option
usepeerdns is not set in /etc/ppp/options.
EOT
fi

#
# SuSE Firewall script: If you installed and configured your firewall
# in /etc/sysconfig/firewall it will be started here:
#
start_firewall

#
# You may choose to use a default firewall script, configured for
# the standard dialup user(install package ipchains):
#
#test -x /etc/ppp/inet_chains.local && /etc/ppp/inet_chains.local "$@"

# maybe you want to start mail services:
# set follow variables in /etc/sysconfig/sendmail
# SENDMAIL_TYPE="yes"
# SENDMAIL_SMARTHOST="<ISP-mailserver>"
# SENDMAIL_ARGS="-bd -om"
# SENDMAIL_EXPENSIVE="yes"
# SENDMAIL_NOCANONIFY="yes"
#/usr/bin/fetchmail -a -v >>/var/log/fetchmail 2>&1 &
#/usr/sbin/sendmail -q &

# As an alternative to the commands above, you can use a seperate script,
# /etc/ppp/poll.tcpip. The default scripts as shipped is able to set the
# system clock using ntpdate (see the XNTPD_INITIAL_NTPDATE setting in
# /etc/sysconfig/xntp). It supports fetchmail with a system-wide
# /etc/fetchmailrc and can use UUCP to fetch mail over TCP/IP, provided
# that UUCP is configured properly. Last not least it also calls sendmail
# to send any queued mail.
if test -z "$IPPARAM" -o -n "${IPPARAM##*no_poll_tcpip*}" ; then
/etc/ppp/poll.tcpip | logger -p security.notice -t poll.tcpip > /dev/null &
fi

# call ip-up.local if it exists and is executable:
if test -x /etc/ppp/ip-up.local ; then
/etc/ppp/ip-up.local "$@" | logger -p security.notice -t ip-up.local > /dev/null &
fi
;;
ip-down)
#
# This code restores the original resolv.conf saved when ip-up
# was called by the pppd which uses the `usepeerdns' option and
# resolv.conf was modified for the supplied dns server adresses.
#
if [ -n "$USEPEERDNS" -a -f /etc/ppp/resolv.conf ]; then
/sbin/modify_resolvconf restore -s pppd -e "$INTERFACE"
fi

#
# SuSE Firewall script: If you installed and configured your firewall
# in /etc/sysconfig/firewall it will be started here:
#
start_firewall

# call ip-down.local if it exists and is executable:
if test -x /etc/ppp/ip-down.local ; then
/etc/ppp/ip-down.local "$@" | logger -p security.notice -t ip-down.local > /dev/null &
fi
;;
*)
;;
esac
;;
*)
# dont know...
;;
esac | logger -p security.notice -t $BASENAME

[Baralis]

genau das hab ich ja auch gemacht :))

Aber die Route wird nicht gesetzt :(
Dann muss ich die Route jedesmal von Hand nachtragen.

Bei SuSE 7.3 hat es ja noch geklappt.
Vielleicht hab ich ja einen Fehler beim Konfigurieren der ISDN-Verbindung gemacht. Da gibt es ja auch noch defaultroute Konfigurationen.

[Belkira]

Original geschrieben von Baralis
Nur leider hab ich das Problem, das ich jedesmal wenn ich ISDN starte der die route nicht automatisch einfügt.

Weil schon die von DSL existiert. Du kannst ipppd zwar mit Option deldefaultroute übergeben und er ersetzt dann auch eine existierende default route. Aber willst Du das wirklich?

[Baralis]

Nein, deswegen hab ich ja auch den Routeneintrag in der ip-up gemacht, der funktioniert aber
Ich hab ISDN auch schon ohne DSL gestartet und er trägt trotzdem keine Defaultroute ein.
Ich weiss auch nicht in wie weit der pppd den ipppd stören kann.
Aber dann muss es ja wenigstens funktionieren, wenn ich den pppd nicht starte.
Das ist doch ein einfacher Befehl in der ip-up, den er doch eigentlich ausführen sollte bei der Einwahl von ISDN. Macht er aber leider nicht, als würde ISDN bei der Einwahl ip-up garnicht ausführen.

[Belkira]

Original geschrieben von Baralis
Ich hab ISDN auch schon ohne DSL gestartet und er trägt trotzdem keine Defaultroute ein.

Das macht er nur mit Option defaultroute und ggf. mit deldefaultroute, wenn eine existierende überschrieben werden soll.

Ich seh bei Deinen Angaben aber weiterhin nicht, wo überhaupt eine "default route" im Spiel ist. Die Route, die Du manuell setzt, ist keine "default route", sondern eine stinknormale Route zu einem Gateway in ein anderes Netz/Subnetz.

Ansonsten kann ich mich zu SuSE nicht weiter äußern. Wenn ip.up nicht ausgeführt wird, hast Du irgendein anderes Problem.

[Baralis]

okok ist ja eigentlich auch egal ob Route oder Defaultroute :)

Dann versuch ich es anders zu erklären.
Ich will eine Route beim starten von ISDN setzen.
Dann habe ich in der Datei /etc/ppp/ip-up unter ippp) ip-up) eine route gesetzt.
Beim starten von ISDN wird diese Route nicht gesetzt. Ich habe dann ein paar echos in die ip-up geschrieben, um zu gucken, ob irgendwas passiert, wenn ich ISDN starte und es passiert garnichts. Also übergeht meine ISDN-Verbindung ip-up. Und jetzt möchte ich gerne wissen warum :)

[Belkira]

Hehehe, das wurde bislang im Thread nicht klar, obwohl es schon im ersten Posting steht. :o Bissel unglücklich formuliert.

Hat /etc/ppp/ip-up (oder wo es bei Dir liegt) ausführbare Rechte?

Wird /etc/ppp/ip-down ausgeführt?

[Baralis]

Auf die Idee war ich auch schon mal gekommen :)
Da ip-down nur ein link auf ip-up ist hatte ich mal ip-up volle Rechte gegeben. Hat aber auch nicht geklappt.

[pitu]

less /etc/ppp/options.ippp0

...

# default route should be set by ipppd
defaultroute

...



wenn das ding nicht gesetzt ist, dann wird auch keine defaultroute gesetzt.

pitu

[Belkira]

Ähem, pitu, das eigentliche Problem in diesem Thread (das haben viele von uns erst übersehen) ist, daß /etc/ppp/ip-up offenbar nicht aufgerufen wird. Dort versucht er nämlich, seine route zu setzen. Stellt sich die Frage, warum ip-up und ip-down nicht aufgerufen werden und wann überhaupt?

[pitu]

Jau, immer erst genau lesen .... *seuftz*

Also, Die routen von allen Devices werden zunaechst mal vom Kernel automatisch gesetzt, da braucht man keine eintraege in der rout.conf mehr.

Natuerlich wird keine defaultroute gesetzt.

Wenn du aber ein ippp0 device aufgesetzt hast, dann muss in dem routing table auch schon eine route auf dein Device vorhanden sein.


Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0
212.185.251.105 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 212.185.251.105 0.0.0.0 UG 0 0 0 ppp0
local:~ # cat /etc/route.conf
local:~ #


Wie du siehst habe ich eine route auf ippp0 und meine route.conf ist leer. Du brauchst also gar keine routen mehr setzten. Wenn du das nicht so hast (bei einer 7.3) hast du irgendwo etwas falsch gemacht.

Was du auch schoen sehen kannst, sind die 2 eth0 routen, die ich drin habe, weil ich frueher mal versehentlich zusaetzlich die route in die route.conf eingetragfen habe. da ich seit dem den rechner nicht mehr runtergefahren habe habe ich nun halt 2 routen auf dasselbe device drin ;-)

Die defaultroute zeigt in diesem fall ins internet und wird vom smpppd gesetzt. wenn ich ins firmennetz will muss ich eben eine adress aus dem ippp0 benutzen.
Du darfst dann von ipppd keine routen mehr setzen lassen.

Genauer gesagt, du musst dem ipppd sagen, dass er keine routen aufmachen darf und die defaultrout n icht setzten darf (letzteres im letzten posting)


local:~ # grep -2 route /etc/ppp/options
# The next two options are only interesting for you if you are admin of
# a system with other users that use ppp, and those users are normally
# never allowed to add default route, or you do not want users to
# replace the default route.
#-------------------------------------------------------------------------

# enable this to prevent users from attempting to add a default route.
# Use this option with caution: If the user needs to use a program like
# wvdial, he will not be able to connect because wvdial forces defaulroute
# but this is rejected by this option and the user will not be able to
# connect to the internet.
#nodefaultroute

# enable this to prevent users from replacing an existing default route.
#noreplacedefaultroute

#-------------------------------------------------------------------------
local:~ #


mit andern Worten du musst die einstellungen, wenn du mit einer festen IP is netzt gehst in der rc.config:

local:~ # grep IFCONFIG /etc/rc.config
# IFCONFIG_0="192.168.81.38 broadcast 192.168.81.63 netmask 255.255.255.224"
IFCONFIG_0="192.168.10.35 broadcast 192.168.10.255 netmask 255.255.255.0 up"
IFCONFIG_1="up"
IFCONFIG_2="192.168.1.99 pointopoint 192.168.1.1 up"
IFCONFIG_3=""
local:~ #


Du musst also fuer das ipp0 device etwas anderes als pointopoint benutzen, da ansonsten als netmask immer 255.255.255.0 verwendet wird. Normalerweise wird dies ja umgesetzt, sobald eine Verbindung aufgebaut wird.

In deinem Fall willst du das aber nicht.

Welchen Daemon hast du ueberhaupt laufen? ip-up wird automatisch gestartet, daran kommst du nicht vorbei.

Wenn du aber nicht den smpppd von SuSE fuer deine ADSL-Verbindung benutzt, wirds problematisch. da der ipppd pppd und pppoed haendelt.

pitu

[Belkira]

In diesem Thread geht es um SuSE 8.0 (ich selbst bin Red Hat Verfechter) und ipppd.

Daß wir angenommen haben, ipppd wolle die default route der DSL Verbindung überschreiben, hatte auch als Grund, daß wir die Route für das ippp0 Device vorausgesetzt haben (zumindest habe ich das) und das Problem beim Setzen einer zweiten default route sahen (siehe die ersten zehn Postings).

Bleibt die Frage, warum hier ip-up nicht ausgeführt wird.

[pitu]

Warum willst du ZWEI defaultroutes haben???? das klappt doch eh nicht. du kannst nur eine haben !!!

Ausserdem habe ich gefrate wie ihr die ADSL-verbindung aufbaut. wenn es SUSE standard ist, dann benutzt ihr pppoed und smpppd, und damit sollte es kein Problem geben. wenn ihr aber rp-pppd benitzt, dann gibt es ein problem, da auch der ipppd von smpppd gestartet wird, den ihr aber nicht benutzt, dann liegt naemlich dort das problem.

ausserdem muesste in der /var/log/messages irgendwo drinstehen, dass er ip-up aufruft, auch bei der dsl-verbindung.

Je nachdem was ihr macht ist halt das problem woanders, deswegen hab ich das alles geschrieben gehabt.

die echos die du angemerkt hats ....


local:~ # head /etc/ppp/ip-up
#!/bin/sh
echo testetstetets
logger ab hier gehts los
...
local:~ # isdnctrl dial ippp0
Dialing of ippp0 triggered
local:~ # tail 10 /var/log/messages
tail: 10: No such file or directory
==> /var/log/messages <==
Jun 23 11:57:34 local ipppd[30708]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 10
Jun 23 11:57:34 local kernel: isdn_net: ippp0 connected
Jun 23 11:57:34 local pppd[21828]: rcvd [LCP EchoReq id=0xf9 magic=0x339cd320 00 00 00 00] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 23 11:57:34 local pppd[21828]: sent [LCP EchoRep id=0xf9 magic=0x6221502e d4 b9 fd 09]
Jun 23 11:57:37 local ipppd[30708]: Remote message:
Jun 23 11:57:37 local ipppd[30708]: MPPP negotiation, He: No We: No
Jun 23 11:57:37 local ipppd[30708]: local IP address 212.125.52.154
Jun 23 11:57:37 local ipppd[30708]: remote IP address 212.162.34.6
Jun 23 11:57:37 local ipppd[30708]: ppp not replacing existing default route to ppp0[212.185.251.105]
Jun 23 11:57:37 local logger: ab hier gehts los


Wie du siehst, kriegst du eh keine echos raus. Wenn du mit sicherheit was feststellen willst, nimm logger. Dann kannst du auch in der /var/log/messages gelich sehen, wann er wo gewesen ist und was sonst nocht so passiert ist.

Und wie gesagt, 2 defaultroutes ist mist, geht nicht, deswegen heist es ja auch default ... wenn alle anderen routes nicht gehen, dann greift die default-route... aber wie soll er sich denn zwischen zweien entscheiden? einfach mal in beide netzte schicken, und dann man schaun was passiert?

Was ist denn wenn du in diesem Fall in beiden netzen diegleiche Adresse drin hast, welche Antwort soll er dann auswerten? die zuerst kommt? Nein, 2 defaults gahen nicht.

pitu

[Belkira]

Original geschrieben von pitu
Warum willst du ZWEI defaultroutes haben???? das klappt doch eh nicht. du kannst nur eine haben !!!
Och, pitu, lies besser nochmal von Anfang an. Du bist noch ebenso verwirrt, wie wir anderen Helfer in diesem Thread es anfangs waren. :rolleyes: ;)

[pitu]

ich les ja schon isch les ja schon

ich glaube meine verwirrung loest sich so langsam ....

trotzdem bleibt noch meine frage, mit welchem dienst dsl gestartet wird ...

Die ip-up wird mit grosser wahrscheinlichkeit abgearbeitet, der pppd meldet dies auch:
Jun 23 10:22:34 local pppd[21828]: Script /etc/ppp/ip-up finished (pid 28584)

der ipppd meldet dies nicht, deswegen wuerde ich gleich am Anfang mal ein "logger" reinschreiben. Wenn der entsprechende kommentar auftaucht, dann kann man mal weitersehen, wenn nicht, dann hast du wie schon diskutiert, viel frueher ein problem, welches aber auch in der /var/log/messages stehen muesste.

pitu

[Baralis]

Ok ich versuchs mal mit "logger" und werd die mal die messages hier rein posten :)

[Baralis]

ok so :)

Jun 24 18:55:43 linux ipppd[1351]: ipppd i2.2.12 (isdn4linux version of pppd by MH) started
Jun 24 18:55:43 linux ipppd[1351]: init_unit: 0
Jun 24 18:55:43 linux ipppd[1351]: Connect[0]: /dev/ippp0, fd: 8
Jun 24 18:56:17 linux ipppd[1351]: Local number: XXXXXXX, Remote number: XXXXXXXX, Type: outgoing
Jun 24 18:56:17 linux ipppd[1351]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 8
Jun 24 18:56:17 linux ipppd[1351]: MPPP negotiation, He: no We: No
Jun 24 18:56:17 linux ipppd[1351]: CCP enabled! Trying CCP.
Jun 24 18:56:17 linux ipppd[1351]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol)
Jun 24 18:56:17 linux ipppd[1351]: ccp_resetci!
Jun 24 18:56:17 linux ipppd[1351]: local IP address XXX.XXX.XXX.XXX
Jun 24 18:56:17 linux ipppd[1351]: remote IP address XXX.XXX.XXX.XXX
Jun 24 18:56:17 linux ipppd[1385]: Can't execute /etc/ppp/ip-up: Permission denied

vielleicht kann mir ja jetzt jemand helfen und sagen, warum die ip-up nicht gestartet wird. Ich danke schon mal im voraus und für die zahlreiche Beteiligung an meinem Problem :)

[Belkira]

Jun 24 18:56:17 linux ipppd[1385]: Can't execute /etc/ppp/ip-up: Permission denied
Welche Rechte hat sie denn? stat /etc/ppp/ip-up Und welche das Verzeichnis selbst?

[Baralis]

Rechte:

drwxr-x--- /etc/ppp -> chmod 750
-rw-r--r-- /etc/ppp/ip-up -> chmod 644

meinst du das ???

[Thomas Mitzkat]

durch setzen der defaultroute gw auf ppp0 wird der aufruf von ip_up wahrscheinlich dennoch durchgeführt, aber ohne eine neue route zu setzen. ergo muss in ip-up erstemal die defaultroute gw gelöscht werden, damit eine neue gesetzt werden kann

route del default gw
route add .....

[Belkira]

-rw-r--r-- /etc/ppp/ip-up -> chmod 644

meinst du das ???
Argh, Du Schlingel! :D (Siehe mein Posting von 21st June 2002 21:15.) Mach die Datei bitte mal ausführbar, also chmod +x /etc/ppp/ip-up und meld Dich dann wieder. ;)

@Thomas

Er will eine normale Route für ippp0, keine default route. Die bleibt auf T-DSL.

[Baralis]

hehe danke :)

die fehlermeldung ist weg, aber die Route wird noch nicht gesetzt.

ich hab in der ip-up 3 logger geschrieben:

ippp*)
logger hier gehts los

ip-up)
logger hier wird ip-up gestartet

ip-down)
logger hier wird ip-down gestartet


in den messages seh ich jetzt, wenn ich isdn starte "logger: hier gehts los",
aber weiter kommt er nicht :(

Aber wir sind schon einen Schritt weiter :) DANKE

[Belkira]

Ich kenn Dein ip-up Skript nicht. Mußt Du halt ein bissel debuggen, indem Du z.B. ganz am Anfang alle dem Skript übergebenen Parameter loggen läßt. Dann läßt sich vielleicht nachvollziehen, wo das Skript möglicherweise vorzeitig aussteigt.

[Thomas Mitzkat]

@belkira:
1. das ip-up-script ist weiter oben komplett wiedergegeben.
2. die datenpakete können nur einmal geroutet werden, weil sie sonst verlorengehen. daher muss die eine route gelöscht werden und die andere neu gesetzt, damit die datenpakete wissen wo es langgeht.

[Baralis]

YUHU ! :) Hab&acute;s geschafft !

ICH DANKE EUCH ALLEN ;)

[Thomas Mitzkat]

Oh Mann, jetzt spuck die Lösung für die Nachwelt auch aus.

[Baralis]

Ich hab einen grossen Fehler gemacht, den ich wohl komplett vergessen hatte. Ich hab die ip-up von SuSE 7.3 übernommen.
Ist eigentlich auch kein Problem, wenn man einen Eintrag löscht.
Und zwar gibt es direkt unter ippp*) den Eintrag:

if [ $found -eq 0 ]; then
echo "Device '$IFACE' not configured in '/etc/rc.config'"
exit 1
fi

wie ich den gelöscht habe lief alles wie von selber.

Naja war sehr dumm von mir, die ip-up von 7.3 zu benutzen.