We had ADSL before fiber was available in our area. The Technical Limit of Service was 18,000 feet. We were at 16,700. When it rained, our service went down. If it was windy, we'd have intermittent service. After a few calls to service, they subtly let me know that if I complained again, they were simply going to declare me out of the service range. Since I didn't want to go back to dialup, I took what I could get until fiber finally came.
Now that we've had a little stroll down nostalgia lane, I'd like to return us to the actual topic of this forum.
I apologize for taking so long to return to this with my results. Blame a cold and my over caution because I am playing with my sole internet connection. I also had some incredibly bad luck (it seems to me) and I'd like some help analyzing that, too.
Let me give you the overview first. The scheme worked, with one minor tweak. I had to add a "sleep 3" in front of the ping test triggered by the linkup. Maybe it takes a moment for the upstream routing table to get adjusted or something. Perhaps I should just try pinging the other end of the PPP link rather than somewhere comparatively far away (8.8.8.8) but I've had inconsistent results with that, though I can't fathom why.
So, our
linkprecmdping now looks like this:
Code:
old_start_precmd="$start_precmd"
start_precmd="linkping_test"
linkping_test() {
sleep 3
if ping -W 3000 -qnc 1 8.8.8.8 > /tmp/linkpingfile ; then
rm /tmp/linkpingfile
else
return 1;
fi
if [ -n "$old_start_precmd" ]
then
$old_start_precmd || return 1
fi
}
I'll spare you the embarrassing missteps I took to get here (such as forgetting to set the execute permission!) but I do want to share with you the big hit and see if anyone has any suggestions.
I took this in little steps, and the first thing I wanted to do was to bring up PPP on the system with the new code in it, so I could just switch back if I had a problem. And that's exactly what happened. The connection would just keep dropping and it would try over and over. I swapped cables. I peered through the (very verbose) PPP log entries. Nothing worked. Finally, on a hunch, I took the entire USB to Ethernet adapter from the original system and, voila! It worked. Then I discovered the race condition above, stupid typing errors, lack of execute permission, and finally the need for an additional brief delay, but basically, it worked.
So - how the actual heck can an otherwise working Ethernet adapter mess things up? My only thought is I wonder if they have registered my MAC address or something on their side. Is that possible? Does anyone know?
Anyway, after comparing the log files line by line between success and failure, both of them get to this(skipping the date stamp, server name, PID, etc) :
Code:
tun0: Phase: PPP Started (ddial mode).
tun0: Phase: bundle: Establish
tun0: Phase: deflink: closed -> opening
tun0: Phase: deflink: Connected!
tun0: Phase: deflink: opening -> dial
tun0: Phase: deflink: dial -> carrier
but after that, the successful connection does
Code:
tun0: Phase: Received NGM_PPPOE_ACNAME (hook "stpl-dsl-gw10.stpl.qwest.net")
tun0: Phase: Received NGM_PPPOE_SESSIONID
tun0: Phase: Received NGM_PPPOE_SUCCESS
tun0: Phase: deflink: carrier -> login
tun0: Phase: Received NGM_PPPOE_SUCCESS
tun0: Phase: deflink: carrier -> login
tun0: Phase: deflink: login -> lcp
tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492
tun0: Phase: bundle: Authenticate
and then my CHAP authentication, while the unsuccessful one pauses for about five seconds and then, with no error or explantion, does
Code:
tun0: Phase: deflink: Disconnected!
tun0: Phase: deflink: carrier -> hangup
tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out
tun0: Phase: deflink: 0 packets in, 0 packets out
tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Feb 6 11:34:38 2026
tun0: Phase: deflink: hangup -> opening
tun0: Phase: deflink: Enter pause (30) for redialing.
and after waiting 30 seconds we go back to
Code:
tun0: Phase: deflink: Connected!
and start the process over, and over again.
Oh! While I have your attention, there's an annoyance I'd like to resolve. I see what "ipv6cp" is on by default, and it errors out without apparent harm when the connection comes up - but how would I disable it? I've read through the manual several times, and I see where it says that "ipv6cp" is on by default, but somehow I'm missing the syntax for how to disable it. I'm sure I'm missing something simple. Anybody know this one?
en.wikipedia.org
