Re: login prompt problem for windows users.
It seems it is an issue of mgetty, not ppp. Once he does get logged in via
bring up the terminal window after dialing he can initate PPP just fine.
The login prompt is not being displayed until after one hits the enter key
once and that seems to be what is making the problem for windows users.
I have everything setup as suggested below or the defaults except that I
turned authenication off with noauth in options.ttyQ1a7. And yes I know
that is a bad idea/secuity issue, I'll fix that later after we get this
login issue worked out.
I know we had this Equinox working fine before, a year or 2 ago the guy we
bought it from had us set it up for him with Debian.
I will try turing off the -s option in inittab and see if that helps.
Thanks,
Chuck
On Tue, 7 Mar 2000, Gerard MacNeil wrote:
> On Sun, 5 Mar 2000, Chuck Peters wrote:
>
> >
> > I sent the following to Equinox tech support, but I was hoping a kind
> > Debian guru can tell me what the problem is.
>
> Guru, not. User of mgetty/PPP, yes.
> >
> > Q07:23:respawn:/sbin/mgetty -D -s 115200 -m '"" ATZ OK"' ttyQ1a7
>
> As long as 'ps' shows the mgetty process running on ttyQ1a7, this will
> work. The values on this line override the settings in
> /etc/mgetty/mgetty.config.
>
> >
> > I also asked Mark to dial in with HyperTerminal to confirm that the login
> ...
> > #
> > * - - /bin/login @
>
> Yes, this is the /etc/mgetty/login.config that resulted in the prompt.
> "Mark" (if he had permissions) would need to fire up PPP from the command
> line at this stage. Since, by default, /etc/ppp is not readable by
> others, Mark needs to be assigned special priviliges to do so.
>
> The "routine way" is to let mgetty hand over the authentication procedure
> to PPP. The user does not actually login, which the following log record
> indicates:
>
> > 03/04 15:46:53 1a7 waiting for ``_'' ** found **
> > 03/04 15:46:55 ##### data dev=ttyQ1a7, pid=12205, caller='none',
> > conn='115200',
> > name='', cmd='/usr/sbin/pppd', user='/AutoPPP/'
>
> It is produced as a result of the /etc/mgetty/login.config (as
> distributed):
> /AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap login debug
>
> Everything is working OK so far. The log record is also you indicator
> that mgetty has finished doing it's thing and has handed off the
> connection to PPP for authentication. Time to look at the PPP
> config/logs.
>
> 1. /etc/ppp/options.ttyQ1a7
> Assuming you are dynamically assigning IP addresses, you would want
> <server.IP.address>:<assigned.IP.address>
>
> 2. /etc/ppp/pap-secrets
> As distributed ...
> # Every regular user can use PPP and has to use passwords from /etc/passwd
> * * "" *
>
> 3. /etc/ppp/options
> which has your PPP default options. On distribution there are no DNS
> servers specified for obvious reasons.
> # Specify which DNS Servers the incoming Win95 or WinNT Connection should use
> # Two Servers can be remotely configured
> ms-dns <useable.dns.server>
> ms-dns <useable.dns.server>
>
> If those settings are complete and correct, you should see the result of
> the attempted login via PPP in /var/log/auth.log
>
> If /etc/syslog.conf is configured with the line
> local2.* -/var/log/ppp.log
> you have a complete session log in /var/log/ppp.log
>
> Add the keyword directive (on a line by itself)
> debug
> to /etc/ppp/options.ttyQ1a7 for a detailed report of what PPP is really
> doing during the authentication/network protocol negotiation.
>
> Note: I change that 'a_ppp' above to a '-' and fight with PAM to have
> mgetty log the PPP connections to the utmp/wtmp files. This enables
> commands like 'who' and 'last' to show results on the dialup servers. It
> looks like the latest version of PPP in the potato distribution has
> stopped the fight between mgetty and PAM (not well tested by myself yet).
>
> ---------------------------------------------------------------------------
> Gerard MacNeil, P. Eng macneil@supercity.ns.ca
> System Administrator
> Supercity Internet Services http://www.supercity.ns.ca
>
>
>
Reply to: