Re: pppd against RADIUS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Leon wrote:
> exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS0 115200 plugin
> radius.so \
> $LOCAL_IP:$REMOTE_IP noipdefault defaultroute connect $DIALER_SCRIPT

Unless the system running this script is itself the remote dial-in host
(which seems unlikely, given the context), that command is incorrect.
You should *not* be including the radius.so plugin.  Remove that.
You're not authenticating your peer using a local RADIUS server on your
side of the link -- quite the opposite; the remote peer is doing that.

In general, you shouldn't have to use $LOCAL_IP:$REMOTE_IP if you're a
regular dial-up client ... but I don't know much about these
vendor-supplied scripts.

You also seem to be missing "user myusername" in the configuration.
Unless the user name you use to log into PPP on that peer happens to be
identically the name of your local host, this probably won't work.

> exec chat -v                                            \
>         TIMEOUT         10                              \
>         ABORT           '\nBUSY\r'                      \
>         ABORT           '\nNO ANSWER\r'                 \
>         ABORT           '\nRINGING\r\n\r\nRINGING\r'    \
>         ''              \rAT                            \
>         'OK-+++\c-OK'   ATH0                            \
>         TIMEOUT         60                              \
>         OK              ATDT$TELEPHONE                  \
>         CONNECT         ''                              \
>         sername:        $ACCOUNT                        \
>         assword:        $PASSWORD                       \
>         DPSCFR--DPSCFR  ppp                             \
>         ~               ''

That almost looks like an OK script, assuming that you really have to do
a text mode log-in before starting PPP.  But see the note further below
-- you're being hurt by your choice of shell, and that's why it's not
working.

One note on it, though: you're not initializing the modem.  Good
practice usually includes initializing the modem properly.  (Usually
with at least "AT&F" for generic modems, and "AT&F1" for USR brand
modems.  Your mileage will vary; see the documentation for your modem.)

> LOG /var/log/messages

This is the key part of any request for pppd help.  ;-}

> Jul 17 14:18:00 linux chat[17860]: expect (/root)
> Jul 17 14:18:00 linux chat[17860]: >ppp^M
> Jul 17 14:18:00 linux chat[17860]: Entering PPP mode.^M
> Jul 17 14:18:00 linux chat[17860]: Async interface address is
> unnumbered (Ethernet0)^M
> Jul 17 14:18:00 linux chat[17860]: Your IP address is 172.28.7.208.
> MTU is 1500 bytes^M
> Jul 17 14:18:00 linux chat[17860]: Header compression will match your system.^M
> Jul 17 14:18:00 linux chat[17860]: ^M
> Jul 17 14:18:04 linux chat[17860]: ~~^?}#@!}!(} }8}"}&} }*} }
> }#}$@#}%}&_}8W}0}'}"}(}"}2}0~~^?}#@!}!)} }8}"}&} }*} }
> Jul 17 14:18:06 linux chat[17860]:

Oops.  Your chat script is wrong.  That "garbage" text is actually PPP
from the peer.

Your shell is expanding "~" on the command line into "/root", and the
peer never sends that string, so the chat script doesn't ever exit.
Change the last line of the chat script to read:

        '~'               ''

Note the quotes around '~' -- to stop the shell expansion.  Better still
would be something like this:

	'PPP mode'	''

Instead of expecting the '~' character (the start of the first PPP
message from the peer), you can just expect the notification that PPP is
starting.  That's enough, and it should make the connection complete
faster because you will be less likely to lose that first message and
require a retransmit.

For what it's worth, it's good practice to put your chat script into a
separate file, and then use chat's "-f" option to read that file.  Doing
that avoids a host of shell-related hysteria.

-- 
James Carlson         42.703N 71.076W         <carlsonj@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Audio Users]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux