PPP connect hangs at "getlogname (AUTO_PPP), read:"

PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

  as an initial attempt to configure PPP as simply as possible, i set up
both the client and the server on my laptop, dialing out thru /dev/ttyS0
connected to an external USR modem, thru a teltone telephone line
emulator, and from there back into a xircom pcmcia modem which is
associated with /dev/ttyS3.  no problem, everything worked fine, resulting
in my laptop having, of course, both a ppp0 and ppp1 interface added to 
it, being both the client and the server at the same time.  (yes, it's 
incestuous, but it's a convenient way to test both sides of the 
connection.)

  having verified that the server side worked, i then set up a small
embedded linux system we have here as the client, installed all of the 
essential client-side stuff on it, and dialed out as before, again thru
the teltone box.

  i tracked the server-side log file /var/log/mgetty.log.ttyS3, and what i 
saw was:

... snip ...
wfr: waiting for ``RING''
04/13 08:51:13 yS3   got: [0a][0d][0a]RING[0d]
04/13 08:51:13 yS3   wfr: rc=0, drn=0
04/13 08:51:13 yS3  send: ATA[0d]
04/13 08:51:13 yS3  waiting for ``CONNECT''
04/13 08:51:13 yS3   got: ATA[0d][0d][0a]CONNECT ** found **
04/13 08:51:27 yS3  send:
04/13 08:51:27 yS3  waiting for ``_''
04/13 08:51:27 yS3   got:  38400[0d][0a] ** found **
04/13 08:51:27 yS3   waiting for line to clear (VTIME), read:
04/13 08:51:27 yS3   utmp + wtmp entry made
04/13 08:51:28 yS3   tio_set_flow_control( HARD )
04/13 08:51:28 yS3   print welcome banner (/etc/issue)
04/13 08:51:28 yS3   getlogname (AUTO_PPP), read:


  and that's where it hung.  i used the equivalent files and chat scripts 
on the embedded system as i did on my laptop, so i'm puzzled why the PPP
negotiation that worked before is hanging now.

  my login.config file contains:

/AutoPPP/ -     a_ppp   /usr/sbin/pppd -chap -pap debug

and i can supply the chat scripts if necessary, but i was hoping that 
someone would know offhand the reason for the hanging at that point in the
process.    what does that call to "getlogname" represent?  i'm not using
any authentication, so i'm not clear on what i'm supposed to be looking 
for at that point.

rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Carlson]

Robert P. J. Day writes:
> 04/13 08:51:28 yS3   tio_set_flow_control( HARD )
> 04/13 08:51:28 yS3   print welcome banner (/etc/issue)
> 04/13 08:51:28 yS3   getlogname (AUTO_PPP), read:

At this point, mgetty is waiting to hear from the peer.  If it appears
to be hung, then this means one or more of the following:

	- serial cable is bad

	- peer isn't running PPP

	- serial configuration is wrong somewhere (incorrect bit rate,
          number of bits per character, or parity)

Since you were able to talk to the modem (getting a "CONNECT" string),
I'd guess that the first option isn't the problem.  The other two are
possibilities.

You might want to start slow by disabling mgetty and using cu or
miniterm to talk to the serial port.  Once you get get bytes to go
back and forth between the peers (which is at the root of the current
problem), then mgetty should do its job and start up pppd.

> /AutoPPP/ -     a_ppp   /usr/sbin/pppd -chap -pap debug

It's not getting that far -- mgetty is not getting anything at all
from the peer.

-- 
James Carlson                                  <carlson@workingcode.com>

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Tue, 13 Apr 2004, Robert P. J. Day wrote:

> ... snip ...
> wfr: waiting for ``RING''
> 04/13 08:51:13 yS3   got: [0a][0d][0a]RING[0d]
> 04/13 08:51:13 yS3   wfr: rc=0, drn=0
> 04/13 08:51:13 yS3  send: ATA[0d]
> 04/13 08:51:13 yS3  waiting for ``CONNECT''
> 04/13 08:51:13 yS3   got: ATA[0d][0d][0a]CONNECT ** found **
> 04/13 08:51:27 yS3  send:
> 04/13 08:51:27 yS3  waiting for ``_''
> 04/13 08:51:27 yS3   got:  38400[0d][0a] ** found **
> 04/13 08:51:27 yS3   waiting for line to clear (VTIME), read:
> 04/13 08:51:27 yS3   utmp + wtmp entry made
> 04/13 08:51:28 yS3   tio_set_flow_control( HARD )
> 04/13 08:51:28 yS3   print welcome banner (/etc/issue)
> 04/13 08:51:28 yS3   getlogname (AUTO_PPP), read:
> 
>   and that's where it hung.

i just had the chance to go back to the working scenario (using my 
laptop as both the client and server), and the mgetty log file showed the 
following:

04/13 09:27:21 yS3   tio_set_flow_control( HARD )
04/13 09:27:21 yS3   print welcome banner (/etc/issue)
04/13 09:27:21 yS3   getlogname (AUTO_PPP), read:~}[df]}#[c0]!  <-- here
04/13 09:27:22 yS3   input finished with '\r', setting ICRNL ONLCR
04/13 09:27:22 yS3   tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
04/13 09:27:22 yS3   match: user='/AutoPPP/', key=''
04/13 09:27:22 yS3   match: user='/AutoPPP/', key=''
04/13 09:27:22 yS3   match: user='/AutoPPP/', key='/AutoPPP/'*** hit!
04/13 09:27:22 yS3   login: utmp entry: a_ppp
04/13 09:27:22 yS3   utmp + wtmp entry made
04/13 09:27:22 yS3   calling login: cmd='/usr/sbin/pppd', argv[]='pppd 
-chap -pap debug'
04/13 09:27:22 yS3   setenv: 'CALLER_ID=none'
04/13 09:27:22 yS3   setenv: 'CONNECT8400'
04/13 09:27:22 yS3   setenv: 'DEVICE=ttyS3'
04/13 09:27:22 ##### data dev=ttyS3, pidƒ51, caller='none', 
conn='38400', name='', cmd='/usr/sbin/pppd', user='/AutoPPP/'


so you can how it got past the "getlogname" entry.  thoughts?

rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Tue, 13 Apr 2004, James Carlson wrote:

> Robert P. J. Day writes:
> > 04/13 08:51:28 yS3   tio_set_flow_control( HARD )
> > 04/13 08:51:28 yS3   print welcome banner (/etc/issue)
> > 04/13 08:51:28 yS3   getlogname (AUTO_PPP), read:
> 
> At this point, mgetty is waiting to hear from the peer.  If it appears
> to be hung, then this means one or more of the following:
> 
> 	- serial cable is bad
> 
> 	- peer isn't running PPP
> 
> 	- serial configuration is wrong somewhere (incorrect bit rate,
>           number of bits per character, or parity)

at the moment, because i'm working with an embedded system, i can't
immediately add some diagnostic utilities that might nail this down, so i
have a specific question.  if you compare the above output (the mgetty log
file from the server) when calling up from the embedded system, to the
following, which shows the dialogue getting past that point when calling
from my laptop:

04/13 09:27:21 yS3   tio_set_flow_control( HARD )
04/13 09:27:21 yS3   print welcome banner (/etc/issue)
04/13 09:27:21 yS3   getlogname (AUTO_PPP), read:~}[df]}#[c0]!
04/13 09:27:22 yS3   input finished with '\r', setting ICRNL ONLCR
04/13 09:27:22 yS3   tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
04/13 09:27:22 yS3   match: user='/AutoPPP/', key=''
04/13 09:27:22 yS3   match: user='/AutoPPP/', key=''
04/13 09:27:22 yS3   match: user='/AutoPPP/', key='/AutoPPP/'*** hit!


notice the apparent response from the client(?) in the successful case:

04/13 09:27:21 yS3   getlogname (AUTO_PPP), read:~}[df]}#[c0]!

  it's still not clear what this response represents.  is the client side
pppd supposed to be sending that "~}[df]}#[c0]!" line?  and in response
to what?  i'm just trying to understand at exactly what point in the 
negotiation things are breaking down.  thanks for any pointers.

rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Carlson]

Robert P. J. Day writes:
> notice the apparent response from the client(?) in the successful case:
> 
> 04/13 09:27:21 yS3   getlogname (AUTO_PPP), read:~}[df]}#[c0]!

Right.

>   it's still not clear what this response represents.

It's the start of a normal LCP Configure-Request packet --

	7E 7D DF 7D 23 C0 21 ...

That decodes as:

	7E	- start of frame marker (see RFC 1662)
	7D DF	- address FF (see RFCs 1662 and 1661)
	7D 23	- control 03 (same)
	C0 21	- PPP Protocol value; Link Control Protocol (LCP)

>  is the client side
> pppd supposed to be sending that "~}[df]}#[c0]!" line?

Yes.

>  and in response
> to what?

The physical link being available.  It's not triggered by anything in
PPP itself -- it's done when PPP starts.

>  i'm just trying to understand at exactly what point in the 
> negotiation things are breaking down.  thanks for any pointers.

The very beginning.  There's no PPP data coming from this peer at all,
and there should be.

-- 
James Carlson                                  <carlson@workingcode.com>

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Bill Unruh]

On Tue, 13 Apr 2004, Robert P. J. Day wrote:

> 
> On Tue, 13 Apr 2004, James Carlson wrote:
> 
> > Robert P. J. Day writes:
> > > 04/13 08:51:28 yS3   tio_set_flow_control( HARD )
> > > 04/13 08:51:28 yS3   print welcome banner (/etc/issue)
> > > 04/13 08:51:28 yS3   getlogname (AUTO_PPP), read:
> > 
> > At this point, mgetty is waiting to hear from the peer.  If it appears
> > to be hung, then this means one or more of the following:
> > 
> > 	- serial cable is bad
> > 
> > 	- peer isn't running PPP
> > 
> > 	- serial configuration is wrong somewhere (incorrect bit rate,
> >           number of bits per character, or parity)
> 
> at the moment, because i'm working with an embedded system, i can't
> immediately add some diagnostic utilities that might nail this down, so i
> have a specific question.  if you compare the above output (the mgetty log
> file from the server) when calling up from the embedded system, to the
> following, which shows the dialogue getting past that point when calling
> from my laptop:

As James said, your system is stuck because it is getting nothing from
the far side. Nothing. 
In the successful case it got the beginning of a ppp LCP  packet.

It may be that y ou forgot to start up ppp on your embedded system. Ie
it is sitting there waiting for something and mgetty is sitting there
waiting for something. You must start up ppp immediately after the
CONNECt is received on your embedded system and have it start sending
out LCP packets. It should not wait for something from the other side
first. That is how AutoPPP works.






> 
> 04/13 09:27:21 yS3   tio_set_flow_control( HARD )
> 04/13 09:27:21 yS3   print welcome banner (/etc/issue)
> 04/13 09:27:21 yS3   getlogname (AUTO_PPP), read:~}[df]}#[c0]!
> 04/13 09:27:22 yS3   input finished with '\r', setting ICRNL ONLCR
> 04/13 09:27:22 yS3   tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
> 04/13 09:27:22 yS3   match: user='/AutoPPP/', key=''
> 04/13 09:27:22 yS3   match: user='/AutoPPP/', key=''
> 04/13 09:27:22 yS3   match: user='/AutoPPP/', key='/AutoPPP/'*** hit!
> 
> 
> notice the apparent response from the client(?) in the successful case:
> 
> 04/13 09:27:21 yS3   getlogname (AUTO_PPP), read:~}[df]}#[c0]!
> 
>   it's still not clear what this response represents.  is the client side
> pppd supposed to be sending that "~}[df]}#[c0]!" line?  and in response
> to what?  i'm just trying to understand at exactly what point in the 
> negotiation things are breaking down.  thanks for any pointers.
> 
> rday
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Tue, 13 Apr 2004, James Carlson wrote:

> The very beginning.  There's no PPP data coming from this peer at all,
> and there should be.

ok, i think i've narrowed this down somewhat.  i've bypassed the scripts 
on the client side and typed in the pppd command manually, and here's what
happens:

# pppd -detach /dev/modem 9600 debug \
> connect "chat -v '' AT OK ATDT102 CONNECT '\d\c'"
Serial connection established.                     <-- a good sign
Couldn't get channel number: Invalid argument      <-- not a good sign
#

"Couldn't get channel number: Invalid argument"?  that sounds like a
fundamental problem at the kernel level, where the kernel itself is unable
to allocate something critical for PPP.

i'm about to go looking for that error message in the kernel source, but
it would go a long way to explaining why the client peer simply fails to 
even start talking PPP, no?

any hints as to what that error message means, and how to fix it, while
i'm hunting?

rday

p.s.  thanks loads for the help thus far, i'm feeling a bit out of my 
depth at the moment.  historically, i remember it being so much easier to 
configure PPP, but i wasn't working with a single-board computer running
embedded linux at the time. :-P

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Carlson]

Robert P. J. Day writes:
> "Couldn't get channel number: Invalid argument"?  that sounds like a
> fundamental problem at the kernel level, where the kernel itself is unable
> to allocate something critical for PPP.

Yes.  It means that the kernel rejected the PPPIOCGCHAN ioctl on
/dev/ppp.  This implies that the kernel's PPP driver implementation is
very far out of sync with the version of user space code in use, or is
otherwise damaged in some way.

> any hints as to what that error message means, and how to fix it, while
> i'm hunting?

Find out what kernel version is in use and what user space bits are in
use.  There's a mismatch somewhere.

> p.s.  thanks loads for the help thus far, i'm feeling a bit out of my 
> depth at the moment.  historically, i remember it being so much easier to 
> configure PPP, but i wasn't working with a single-board computer running
> embedded linux at the time. :-P

It shouldn't be so hard ... :-/

-- 
James Carlson                                  <carlson@workingcode.com>

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Tue, 13 Apr 2004, James Carlson wrote:

> Robert P. J. Day writes:
> > "Couldn't get channel number: Invalid argument"?  that sounds like a
> > fundamental problem at the kernel level, where the kernel itself is unable
> > to allocate something critical for PPP.
> 
> Yes.  It means that the kernel rejected the PPPIOCGCHAN ioctl on
> /dev/ppp.  This implies that the kernel's PPP driver implementation is
> very far out of sync with the version of user space code in use, or is
> otherwise damaged in some way.

ok, that might make sense.  the kernel we're using for the embedded system
is a hacked version of 2.4.22-pre8, in which the PPP files have internal
version numbers of 2.4.2.

the user space code on the system is, OTOH, ppp-2.4.1.  is that enough of
a mismatch to be causing all this grief?  i can fairly quickly upgrade to 
the user space 2.4.2 stuff if that's the obvious problem.

rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Carlson]

Robert P. J. Day writes:
> ok, that might make sense.  the kernel we're using for the embedded system
> is a hacked version of 2.4.22-pre8, in which the PPP files have internal
> version numbers of 2.4.2.
> 
> the user space code on the system is, OTOH, ppp-2.4.1.  is that enough of
> a mismatch to be causing all this grief?  i can fairly quickly upgrade to 
> the user space 2.4.2 stuff if that's the obvious problem.

Unfortunately, it's not that simple.  The Linux kernel version
numbering is completely separate from ppp's version numbering.  Pppd
runs on quite a few systems other than Linux (in fact, it ran on BSD
systems *first*), so it's mostly confusing coincidence that the
numbers look similar.

Look at README.linux in the ppp-2.4.1 source directory.

ppp-2.4.1 should support a 2.4.22 kernel just fine, so it's possible
that this one module (ppp_generic.o) is stale or mangled, or that your
kernel was compiled with an odd set of include files.

-- 
James Carlson                                  <carlson@workingcode.com>

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Tue, 13 Apr 2004, James Carlson wrote:

> Unfortunately, it's not that simple.  The Linux kernel version
> numbering is completely separate from ppp's version numbering.  Pppd
> runs on quite a few systems other than Linux (in fact, it ran on BSD
> systems *first*), so it's mostly confusing coincidence that the
> numbers look similar.
> 
> Look at README.linux in the ppp-2.4.1 source directory.
> 
> ppp-2.4.1 should support a 2.4.22 kernel just fine, so it's possible
> that this one module (ppp_generic.o) is stale or mangled, or that your
> kernel was compiled with an odd set of include files.

i've run through checking files and recompiling just to be on the safe 
side, and i'm pretty much out of ideas.

the user space PPP utils on both systems (embedded and fedora core laptop) 
are 2.4.1.  the kernel space PPP code is (internally) 2.4.2 on both.  
we're using the ELDK 3.0 PPC toolchain for cross-compiling everything
for the embedded system, kernel and utils included.

connecting with PPP both out of, and into, the laptop works fine.
it's only when i switch to using the embedded system as the client that
i get that maddening:

  Serial connection established.
  Couldn't get channel number: Invalid argument

as i understand it, this message represents some sort of
incompatibilty/mismatch between the user space PPP code and the kernel
code on the embedded system.  it has nothing to do with the server side,
since it hasn't even got that far, is that accurate?

like i said, i'm baffled.  the code versions suggest that they'd be 
compatible, both the user space code and the kernel were compiled with the
same cross-compiler, i'm pretty sure i've got the right kernel config
parameters for basic PPP.

i suspect it's time to just go drink heavily.  argh.


rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Carlson]

Robert P. J. Day writes:
> as i understand it, this message represents some sort of
> incompatibilty/mismatch between the user space PPP code and the kernel
> code on the embedded system.  it has nothing to do with the server side,
> since it hasn't even got that far, is that accurate?

It's this code on the client that fails (pppd/sys-linux.c):

	/* Open an instance of /dev/ppp and connect the channel to it */
	if (ioctl(fd, PPPIOCGCHAN, &chindex) = -1) {
	    error("Couldn't get channel number: %m");
	    goto err;
	}

I botched my earlier hastily-concocted analysis, though.  It's not
doing that ioctl on the /dev/ppp driver; it's doing it on 'fd' which
is connected to the serial device.  On 2.4.x, that should be handled
in drivers/net/ppp_async.c.

So, check to see:

	- Definition of PPPIOCGCHAN used for compiling ppp_async.o and
          pppd/sys-linux.o is the same.  (Should be from a common
          <linux/if_ppp.h> include file.  Note that there's an extra
          one of these shipped helpfully with the pppd sources, and if
          that's out of step with your kernel, then you're in trouble.)

	- ppp_async.o was really compiled with this kernel and isn't
          from some other system.

	- Kernel was compiled to support ppp_async (CONFIG_PPP_ASYNC
          set to 'm' or 'y' in the 'config' file).

> i suspect it's time to just go drink heavily.  argh.

It's always time for that ...

-- 
James Carlson                                  <carlson@workingcode.com>

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

man, this is getting tedious, my apologies to everyone on the list.
argh.

On Tue, 13 Apr 2004, James Carlson wrote:

> It's this code on the client that fails (pppd/sys-linux.c):
> 
> 	/* Open an instance of /dev/ppp and connect the channel to it */
> 	if (ioctl(fd, PPPIOCGCHAN, &chindex) = -1) {
> 	    error("Couldn't get channel number: %m");
> 	    goto err;
> 	}

yup, i already found that and was trying to figure out if there was
something obvious that was dying.
 
> I botched my earlier hastily-concocted analysis, though.  It's not
> doing that ioctl on the /dev/ppp driver; it's doing it on 'fd' which
> is connected to the serial device.  On 2.4.x, that should be handled
> in drivers/net/ppp_async.c.
> 
> So, check to see:
> 
> 	- Definition of PPPIOCGCHAN used for compiling ppp_async.o and
>           pppd/sys-linux.o is the same.  (Should be from a common
>           <linux/if_ppp.h> include file.  Note that there's an extra
>           one of these shipped helpfully with the pppd sources, and if
>           that's out of step with your kernel, then you're in trouble.)

in the kernel source tree, we have the file include/linux/if_ppp.h, 
containing: 
  ...
  *  =FILEVERSION 20000724=
  ...
  #define PPPIOCGCHAN  _IOR('t', 55, int)  /* get ppp channel number */
  ...

in the ppp-2.4.1 source, also in the file include/linux/if_ppp.h, we
have:
  ...
  *  =FILEVERSION 20000724=
  ...
  #define PPPIOCGCHAN  _IOR('t', 55, int)  /* get ppp channel number */
  ...

no obvious mismatch there.
 
> 	- ppp_async.o was really compiled with this kernel and isn't
>           from some other system.
> 
> 	- Kernel was compiled to support ppp_async (CONFIG_PPP_ASYNC
>           set to 'm' or 'y' in the 'config' file).

ppp async is compiled into the kernel.  but i also just noticed that
ppp sync is there as well, i'm hoping it's not a problem to have them
both built into the kernel.

again, i'm baffled.  this started out as such a simple exercise ...

rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Cameron]

G'day, a different James here ...

Robert P. J. Day wrote:
> ppp async is compiled into the kernel.  but i also just noticed that
> ppp sync is there as well, i'm hoping it's not a problem to have them
> both built into the kernel.

I don't think that both being built should be a problem.  

The two PPTP projects regularly find users who have compiled the PPP
components into the kernel, yet they do not function for them unless
they are compiled as modules.  We haven't got to the bottom of this.  We
even have evidence of a few people finding it works fine built
statically.

So I would suggest building the PPP kernel components as modules, just
to see if it makes any difference.  ;-)

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Wed, 14 Apr 2004, James Cameron wrote:

> G'day, a different James here ...

ok, i think i can handle more than one. :-)
 
> Robert P. J. Day wrote:
> > ppp async is compiled into the kernel.  but i also just noticed that
> > ppp sync is there as well, i'm hoping it's not a problem to have them
> > both built into the kernel.
> 
> I don't think that both being built should be a problem.  
> 
> The two PPTP projects regularly find users who have compiled the PPP
> components into the kernel, yet they do not function for them unless
> they are compiled as modules.  We haven't got to the bottom of this.  We
> even have evidence of a few people finding it works fine built
> statically.
> 
> So I would suggest building the PPP kernel components as modules, just
> to see if it makes any difference.  ;-)

ok, i can do that.  i'm about to head out for food, but i'm prepared to 
spend some time later or tomorrow doing whatever debugging people want to 
suggest.  this is really pretty important for our project, so i 
desperately need a solution.

rday

p.s.  i'm assuming you're suggesting building *all* of the PPP components
as modules?

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Cameron]

Robert P. J. Day wrote:
> p.s.  i'm assuming you're suggesting building *all* of the PPP
> components as modules?

Yes.  Here's my 2.6.2 .config, for what it's worth ...

CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[Robert P. J. Day]

On Wed, 14 Apr 2004, James Cameron wrote:

> Robert P. J. Day wrote:
> > p.s.  i'm assuming you're suggesting building *all* of the PPP
> > components as modules?
> 
> Yes.  Here's my 2.6.2 .config, for what it's worth ...
> 
> CONFIG_PPP=m
> CONFIG_PPP_MULTILINK=y
> CONFIG_PPP_FILTER=y
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_SYNC_TTY=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_BSDCOMP=m

ok, i'll give that a shot.  and to clarify what someone suggested earlier, 
we shouldn't be concerned that our user space PPP is version 2.4.1, while
the kernel code is labelled as 2.4.2, right?

someone else here just suggested downloading the 2.4.2 user space code,
but based on what i read, i thought that that wouldn't make a big 
difference.  is that a fair assessment?

rday

Re: PPP connect hangs at "getlogname (AUTO_PPP), read:"

[James Cameron]

On Thu, Apr 15, 2004 at 09:26:20AM -0400, Robert P. J. Day wrote:
> ok, i'll give that a shot.  and to clarify what someone suggested earlier, 
> we shouldn't be concerned that our user space PPP is version 2.4.1, while
> the kernel code is labelled as 2.4.2, right?

In theory it shouldn't be a problem.  I have evidence (from PPTP users)
that it doesn't work, but only in the context of the MPPE module, and
when the 2.4.1 version is a patched derivative of the mainstream 2.4.1.
Since I don't think you're using MPPE, I have no solid facts to report.

> someone else here just suggested downloading the 2.4.2 user space code,
> but based on what i read, i thought that that wouldn't make a big 
> difference.  is that a fair assessment?

It should not make a big difference, but it's certainly worth trying
just to exclude it as a wild possibility.  Bah, consumer engineering.
;-)

I've had a think after reviewing the ioctl() in sys-linux.c, and an
rgrep of kernel sources for 2.4.24 ... and wondering if instrumenting
the kernel would help to determine the cause of the failure.

drivers/net/ppp_async.c:1004 is the handler for the PPPIOCGCHAN ioctl,
in ppp_asynctty_ioctl().  Your manual pppd attempt showed an EINVAL,
which isn't a return that ppp_asynctty_ioctl() explicitly gives.  It
might return ENXIO (No such device or address), or EFAULT (Bad address),
or success.

But I'm not yet sure what calls ppp_asynctty_ioctl(), I haven't dug deep
enough.  Sorry.  Maybe the caller is returning EINVAL.

Have a look at /proc/tty/ldiscs to make sure ppp is mentioned there.  If
it is not, then ppp_async_init() has not run.  The ppp line is removed
if one types "rmmod ppp_async".

Another wild question; what's the architecture of the embedded system?

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/