[NTLUG:Discuss] pppd troubleshooting

[. Daniel]

For anyone interested here's where I am so far:

It seems thing were working better than I had at first anticipated.  I 
neglected to notice that my resolv.conf was not being updated (as 
documentation asserts it should) when pppd connects to the remote site.  It 
still doesn't.  I don't know why it doesn't.

As for non-root access to serial devices, it turns out that the easy (and 
most correct) fix is to make the user account(s) a member of the "uucp" 
group.  This is evidenced by doing an "ls -l /dev/tty*"  You will see that 
group ownership of these devices is uucp.

Routing was apparently not the issue I assumed it was -- I simply 
misinterpreted the symptoms I observed.

And for the moment, I am unclear as to what the "correct" way to set up and 
establish a PPP connection should be.  I run under GNOME on FC5 and there 
is "GNOME PPP" available though it seems far less than robust... it could 
be that perhaps its complexity and power are masked in some way, I haven't 
investigated beyond the very simple UI and configuration screens.  Instead, 
I wrote a simple procedural shell script (no loops or conditionals) that 
backs up the resolv.conf file, copies one that matches my PPP service 
providers' specs in its place, then starts the pppd session.  Once pppd 
ends, it restores the previous state of resolv.conf.  This is all done in a 
script called in a terminal window so that I can CTRL-C to end the pppd 
session correctly.  (Closing the window results in premature ending of the 
script leaving the resolv.conf with incorrect contents.)

I haven't investigated the use of any KDE ppp software yet.


> >On 7/8/06, . Daniel <xdesign at hotmail.com> wrote:
> > > Here's the scenario:
> > >
> > > I've got this EVDO card from work.  Initially I set it up under
>Windows.
> > > It works, so it should be fine here [under Linux] too.  It's not, so
>I'll
> > > do my best to detail what I have found.
> > >
> > > Upon hot-plugging the PCMCIA device into the machine, the hardware 
was
> > > correctly identified and appropriate modules were loaded.  In this
>case,
> > > "usbserial" and "airprime."  Two serial devices are created as
> > > "/dev/ttyUSB0" and "/dev/ttyUSB1" where ttyUSB0 is the modem device.
>As
> > > root, I can talk to the device, but as a user, I cannot.  It would be
>good
> > > to be able to talk to it as non-root, but that's fine for now, but it
>did
> > > slow my progress for an hour or longer as I had to figure out that it
>was
> > > "root access only" before I could gain access to the modem device on
> > > ttyUSB0.
> > >
> > > Once I learned I needed to run all access to /dev/ttyUSB0 as root, I
>was
> > > able to run wvdialconf and all that as documented here:
> > >
> > > http://www.cs.drexel.edu/~kfu22/evdo/
> > >
> > > Pretty much everything works as evidenced by the logs I have 
attached.
> > > (Hope I can attach text files with this email, else, I will follow up
>with
> > > a second email with cut-n-paste.)  The problem now is that while I 
can
>ping
> > > the gateway, I cannot route beyond that.  My guess is that there 
might
>be
> > > some sort of authentication that isn't being addressed.  But perhaps
>some
> > > fresh eyes on the problem could reveal something I haven't yet 
noticed?
> > >
> > >
> >
> >Try:
> >/sbin/route add default gw 68.28.177.69
> >
>I was able to see the attachments in the message I sent previously.  The
>output of my route command illustrated that my default route was set to 
the
>gateway.  The traceroute output also showed that up to four other IP
>addresses appeared as well, though I did not attempt to ping them.  But
>yes, the default route was set appropriately.
>
>
>
>_______________________________________________
>http://ntlug.pmichaud.com/mailman/listinfo/discuss