Marv et al.,
This thread can now be closed because the problem has been identified
albeit not solved: it is particular to Guillaume's ISP. His modem and
setup run normally when he dials my ISP instead of his.
All other interfaces but lo were closed, the DNS were correctly set to
the ppp ISP, etc... Not the classical DNS "problem".
I am awaiting a report by Guillaume about pinging the remote IP.
/var/log/messages sent with my query had reported a failure to obtain
LCP answers issued by the local IP.
Guillaume is a student with a lot of other work and a beginner Linux
user. I am dumping on him a lot of tests. Next to come will be using the
debug option of pppd to see what are these unanswered LCP requests.
I can't go further because his French ISP (mine too, with which he
smoothly connects) uses the French flavor of an 800 number which cannot
be reached from outside France.
There is one thing which I have not digested yet, I must say. How can
pppd work without any route displayed by route -n while the
connection is established? Automatically uses the remote IP when no
route exists
Thanks - Jacques
Marvin Stodolsky wrote:
Guillaume
COMM channels except "lo" loopback have to be closed before starting a
dialout, or the PPPD will try to use the ethernet DNS settings, which
will not work for PPPD
So
$ ifconfig
$ sudo ifconfig eth0 down
Check again with
$ ifconfig
If necessary
$ sudo ifconfig eth1 down
$ ifconfig
When only the "lo" channel is left,
start the dialout.
MarvS
On Feb 4, 2008 10:43 AM, Jacques Goldberg <Jacques.Goldberg@xxxxxxx> wrote:
Folks,
I fail trying to solve this one myself.
The wvdial session starts fine, pppd session Ok, local and remote access
Ok, DNS set and correct.
Access Web site: no server replies. After a couple of minutes, wvdial exits.
I noticed a default route 0.0.0.0 while the connection is up.
I thought I got it.
But same Ubuntu 7.10 running on my PC (Live) with my HSF modem does just
the same and the connection works.
Also both Guillaume and I do not have defaultroute neither in
/etc/ppp/options nor in /etc/ppp/if-up.d
Guillaume will test later today enforcing a usual default route set to
the remote IP address.
I am stunned to see ETH1 in the following excerpt from /var/log/messages:
Feb 3 11:01:03 LinuX-Guillaume kernel: [ 267.712000] lo: Disabled
Privacy Extensions
Feb 3 11:01:03 LinuX-Guillaume pppd[5799]: Using interface ppp0
Feb 3 11:01:03 LinuX-Guillaume pppd[5799]: Connect: ppp0 <--> /dev/pts/1
Feb 3 11:01:07 LinuX-Guillaume kernel: [ 272.132000] PPP BSD
Compression module registered
Feb 3 11:01:07 LinuX-Guillaume kernel: [ 272.192000] PPP Deflate
Compression module registered
Feb 3 11:01:09 LinuX-Guillaume pppd[5799]: local IP address
193.249.111.208
Feb 3 11:01:09 LinuX-Guillaume pppd[5799]: remote IP address
193.252.253.188
Feb 3 11:01:09 LinuX-Guillaume pppd[5799]: primary DNS address
80.10.246.5
Feb 3 11:01:09 LinuX-Guillaume pppd[5799]: secondary DNS address
80.10.246.136
Feb 3 11:01:20 LinuX-Guillaume kernel: [ 285.320000]
ADDRCONF(NETDEV_UP): eth1: link is not ready
Feb 3 11:02:50 LinuX-Guillaume syslogd 1.4.1#21ubuntu3: restart.
Feb 3 11:03:38 LinuX-Guillaume pppd[5799]: No response to 4 echo-requests
Feb 3 11:03:38 LinuX-Guillaume pppd[5799]: Serial link appears to be
disconnected.
Feb 3 11:03:38 LinuX-Guillaume pppd[5799]: Connect time 2.5 minutes.
Has anybody met such a condition before?
Thanks - Jacques
