[lug] browser not opening url, connect is ok

Sat Jun 30 15:59:51 MDT 2001

"D. Stimits" wrote:
> 
> Rob Mohr wrote:
> >
> > Hello BLUG,
> >
> > I can connect via wvdial or minicom.  And I get as far as starting ppp
> > enter.  But the browser does not open on any url.  Do I have to link or
> > config the browser in some fashion? What files?  what is the config name?
> > Note, pppd starts fine.  Also, I called the ISP and he said to try
> > pinging.  Pinging works prior to starting ppp mode.  It does not work
> > after ppp mode has begun.  Different browsers, chimeria, Mozilla, work
> > fine with respect to opening files, pixes either on the hdaX or cdrom.
> >
> > Again, the problem is no action on the url in the browser save for the
> > nominal timeout "can't open." (Where do I change the timer for this?)
> > eof
> >
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> In addition to what Hugh said, you might want to run "route", and for
> ppp0, see if it has an entry for "default" (there would probably be two
> ppp0 entries, one for the ISP's endpoint, and a route entry if it is
> default). You want a default route associated with ppp0. If you don't
> have that, see if doing this helps:
> route add default ppp0
> (not sure if you'll need to use "gw" for gateway argument as well)
> 
> D. Stimits, stimits at idcomm.com

Thought of one more test, if you are able to network, but if browsing
still fails. Manually do "telnet wherever.com 80". Type "GET" at the
prompt, and see if it returns a page. You could log this way:
telnet somesite.com 80 | tee weblog.html

Then if you edit weblog.html, and delete the actual command line stuff,
such that the first line that remains is the <!DOCTYPE HTML.... stuff,
then your browser should be able to open that file and view the page
without networking getting in the way. You could test it for errors with
weblint (to decide if the html might be breaking the browser and not
really being another fault).

D. Stimits, stimits at idcomm.com