No, I didn't, but now with such parameter is works fine.
To share my experience, I send you now Server and
Client configurations. Both are working fine.
Server (Called system) side
This node is linked to a LAN and has a default route.
File /etc/passwd
YYYYY:x:513:44::/home/pppu:/usr/sbin/pppd
Do not forget to passwd YYYYY with ZZZZZ
File options
Blank file. Nothing on as used both for outgoing and incoming calls.
/dev/ttyC2 is the device linked to a modem ready to answer
/etc/inittab
# Async In Modem
l9:2345:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyC2 ttyC2 115200
vt100
File /etc/default/uugetty.ttyC2
# line to initialize
INITLINE=ttyC2
# timeout to disconnect if idle...
TIMEOUT=60
# modem initialization string...
# format: <expect> <send> ... (chat sequence)
INIT="" AT\r OK\r\n
WAITFOR=RING
CONNECT="" ATA\r CONNECT\s\A
# this line sets the time to delay before sending the login banner
DELAY=1
File options.ttyC2
asyncmap a000
passive
crtscts
debug
noauth
modem
lock
idle 30 (I know, it is a shot time but enough if you want to keep open
the line generating some traffic)
defaultroute
File ip-up.local
This script is used to close the line if activated out of a given
time frame:
#!/bin/bash
IntrfcNm=$1
TtyDv=`basename $2` # Cause receiving dev/ttyXX
Spd=$3
LclIp=$4
RmtIp=$5
Prm=$6
TmFrm="0800"
TmTo="2000"
KillPrcs() {
for Prcs in `ps -e | grep $TtyDv | grep pppd | awk '{ print $1 }'`
do echo " Call out of allowed time .$TmFrm. .$TmTo. .$Tm." >> /tmp/Ppp.lg
echo " Killing process $Prcs" >> /tmp/Ppp.lg
kill -1 $Prcs
done
}
Tm=`date '+%H%M'`
echo "Connect from $IntrfcNm $TtyDv $LclIp $RmtIp $Prm" >> /tmp/Ppp.lg
echo " Time $Tm" >> /tmp/Ppp.lg
if [ "$Tm" \< "$TmFrm" ] ; then
KillPrcs
fi
if [ "$Tm" \> "$TmTo" ] ; then
KillPrcs
fi
exit 0
Client (calling system)
This node is linked to a LAN and has a default route
File ppp.opt
connect ppp.chat
debug
crtscts
modem
ipcp-accept-local
ipcp-accept-remote
default-asyncmap
nodefaultroute
noipdefault
updetach
lock
File ppp.chat
/usr/sbin/chat -v ABORT 'NO CARRIER' "" "ATZ\r" "OK" "ATM0" "OK" \
"ATDTXXXXXXXX" \
"ogin:" "YYYYY" "ord:" "ZZZZZ"
Calling run
/usr/sbin/pppd file ppp.opt ttyC0 115200
Et voilà my friends.
If I can help some one in return, you know the e-mail
Thanks folks !
>>>>>>>>>>>>>>>>>> Message d'origine <<<<<<<<<<<<<<<<<<
Le 6/19/01, à 12:55:23 PM h, Walker Traylor
<wtraylor@professionalsites.com> vous a écrit sur le sujet suivant Re: PPP
Client Configuration on a system having a default route:
> Edouard,
> Have you tried adding "noauth" to the config of one of the boxes?
> --Walker
> On Tue, 19 Jun 2001, Edouard Soriano wrote:
> > Hello guys,
> >
> > I have a little problem for which I am getting out of ressources.
> >
> > Trying to configure a Linux system linked to a LAN having a Default Route
> > (192.168.1.50)
> >
> > On that system I would like to configure a PPP Client connection to a
> > Linux system which will provide my IP address on that connection.
> >
> > This is my Client ppp.opt file configuration:
> >
> > connect ppp.chat
> > debug
> > crtscts
> > modem
> > ipcp-accept-local
> > ipcp-accept-remote
> > default-asyncmap
> > nodefaultroute
> > noipdefault
> > updetach
> > lock
> >
> > The ppp.chat works fine.
> >
> > All gets fine but at the end of the handshaking I get on my
> > client log:
> >
> > rcvd [IPCP ConfAck id=0x2 <addr 192.168.250.2> <compress VJ 0f 01>]
> > Peer is not authorized to use remote address 192.168.250.1
> > sent [IPCP TermReq id=0x3 "Unauthorized remote IP address"]
> >
> > This problem gets out when deleting on the client system the
> > Default Route (192.168.1.50) means when the client has no
> > default route before initiating the outgoing call.
> >
> > I tried to turn around this problem adding on the Client
> > ppp.opt file:
> >
> > allow-ip 192.168.250.
> >
> > but that's changed nothing.
> >
> > Any idea bout ?
> >
> > Thanks in advance.
> >
> >
> > -
> > : send the line "unsubscribe linux-net" in
> > the body of a message to majordomo@vger.kernel.org
> >
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
