Thanks Gus. That's *just* what I needed to get me over the hump (the
tip about minicom).
Ralph Shumaker wrote:
Anyway, here on rh9, su is able to get a response from /dev/ttyS4, so
now for fc3.
On fc3, did "minicom -c" where I changed the default from /dev/ttyS1 to
/dev/ttyS4.
Then "minicom" initialized the modem, "at" worked, so I figured "what
the hell", and went ahead and did "atdt555-myISP". It responded
"CONNECT 26400 V42bis". I logged in. It informed me "Entering PPP
Session." and "IP address is xx.xx.xx.xx" and "MTU is 1500". But
firefox couldn't find <http://www.redhat.com>.
Although this probably had no bearing on my problem, I discovered that
there was no link "/dev/modem" so I "ln -s /dev/ttyS4 /dev/modem". This
brought about no change that I could detect. (IOW, a repeat of the
previous paragraph went no differently.)
I tried wvdial (which is the backend of what gets me surfing in rh9). I
had to address a few issues in wvdial.conf but finally got it to where
it was complaining about just one of the init strings (the shorter of
the two fortunately "atm1l4". I couldn't find anything anywhere about
the commands and couldn't quite remember them so I went back to
minicom. After it initialized the modem, I commanded "at" and got
"ok". Then "atm1" and got "ok". Then "atl4" and got "Error" (or
somesuch). Then "atl3", "atl5", "atl2", and "atl4" (for good measure)
and got "ok", "Error", "ok", and "Error". Switched back to wvdial.conf,
changed l4 to l3, launched wvdial, and viola! CONNECT! But Firefox
*still* would not surf. So I killed wvdial.
Then I launched the frontend for wvdial through the menu item Network
Device Control under System Tools. Before this, it had always given me
"Error 8" (or somesuch). This time it actually dialed. But during the
handshaking, the tones seems to stall. This happens occasionally when
dialing up with rh9. The difference is that in rh9 I was able to kill
such stalls by launching a second instance and choosing "Deactivate".
(The first instance doesn't give that option until after the connection
completes.) But here in fc3, no matter what I tried, I could not kill
it. Clicking "Deactivate" went ignored, even from a second instance. I
found the lock file and killed it. I still could not "Deactivate".
With the lock file gone, I tried starting minicom again, and its init
actually bumped the modem out of its stall with a reset, but wvdial
immediately started dialing again. This time it connected. At least
Firefox was now able to surf. But I still could not shut it off. I
even used "touch" to create a new lock file in place of the old one, but
to no avail. Finally I had to try rebooting. During the shutdown steps
listed on the screen, I saw "Shutting down {ppp connection}
[successful]". What did *it* do that I didn't?
Anyway, I brought fc3 back up, launched the Network Device Control,
connected, surfed, and disconnected without incident. Whew! So I guess
I now know how to get connected (via modem) on fc3.
Now, I guess I'm ready to blow away the test install of fc3 and actually
upgrade my rh9 (with a good backup, of course).
Why would the Internet Connection Wizard write an invalid option into
the wvdial.conf? Oh well, now that I know about it, all seems well.
(Hopefully I won't have to reboot every time the handshaking stalls,
because that happens probably between 10-25% of the time.)
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
