My word...
I have been having exactly this same problem, and this is after a whole
month of trouble-free operation... why is the damn thing dropping
connections?
I know this wasn't very helpful, but I want to add my name to the chorus. I
expect to take another stab at this problem later in the week. Perhaps I'll
have better luck.
> Further to the pppd problem (I swore I'd had enough for today, but of
> course, I kept wanting to try One More Thing).
Spoken like a true geek.
> a. I have now installed the very lastest ppp from rpmfind; the same still
> happens.
>
> b. The failure occurs regardless of whether I am root or an ordinary user.
>
> c. the options file currently contains:
> lock
> crtscts
> defaultroute
> noauth
> debug
> kdebug 3
>
> d. I have a somewhat more expansive log now:
>
> Aug 27 14:57:09 localhost pppd[928]: pppd 2.4.0 started by root, uid 0
> Aug 27 14:57:10 localhost chat[929]: send (ATDT3034427097^M)
> Aug 27 14:57:10 localhost chat[929]: expect (CONNECT)
> Aug 27 14:57:30 localhost chat[929]: ATDT3034427097^M^M
> Aug 27 14:57:30 localhost chat[929]: CONNECT
> Aug 27 14:57:30 localhost chat[929]: -- got it
> Aug 27 14:57:30 localhost chat[929]: send (^M)
> Aug 27 14:57:30 localhost chat[929]: expect (name:)
> Aug 27 14:57:30 localhost chat[929]: 26400/ARQ/V34/LAPM/V42BIS^M
> Aug 27 14:57:31 localhost chat[929]: ^M
> Aug 27 14:57:31 localhost chat[929]: ^M
> Aug 27 14:57:31 localhost chat[929]: User Access Verification^M
> Aug 27 14:57:31 localhost chat[929]: ^M
> Aug 27 14:57:31 localhost chat[929]: Username:
> Aug 27 14:57:31 localhost chat[929]: -- got it
> Aug 27 14:57:31 localhost chat[929]: send (n7dr^M)
> Aug 27 14:57:31 localhost chat[929]: expect (word:)
> Aug 27 14:57:31 localhost chat[929]: ^M
> Aug 27 14:57:31 localhost chat[929]: Username: n7dr^M
> Aug 27 14:57:31 localhost chat[929]: Password:
> Aug 27 14:57:31 localhost chat[929]: -- got it
> Aug 27 14:57:31 localhost chat[929]: send (<password goes here>^M)
> Aug 27 14:57:31 localhost pppd[928]: Serial connection established.
> Aug 27 14:57:31 localhost kernel: ppp_ioctl: set dbg flags to 30000
> Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 30000
> Aug 27 14:57:31 localhost pppd[928]: Using interface ppp0
> Aug 27 14:57:31 localhost pppd[928]: Connect: ppp0 <--> /dev/modem
> Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xasyncmap
> Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xmit asyncmap
ffffffff
> Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 30000
> Aug 27 14:57:31 localhost kernel: ppp_ioctl: set mru to 5dc
> Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
> Aug 27 14:57:33 localhost kernel: ppp: channel ppp0 closing.
> Aug 27 14:57:33 localhost pppd[928]: Hangup (SIGHUP)
> Aug 27 14:57:33 localhost pppd[928]: Modem hangup
> Aug 27 14:57:33 localhost pppd[928]: Connection terminated.
> Aug 27 14:57:34 localhost pppd[928]: Exit.
>
> The only thing that this suggests to me is perhaps that the "Hangup
> (SIGHUP)" does _not_ mean that a SIGHUP was received, but rather that one
> was sent to hang up the modem (i.e., it is an effect rather than a cause).
> In either case, it still isn't at all obvious what causes the essential
> failure to connect (or, perhaps, "failure to remain connected" is a better
> description).
No, it's not clear at all.
I haven't been getting the SIGHUP -- but I imagine that you get this since
you turned debugging output on? Are you *sure* that pppd isn't receiving a
SIGHUP? If it *is*, I would have no idea where that might be coming from...
-Stephen-
