Bug 9160 - WvDial can fail on some (correct) entries in /etc/hosts
WvDial can fail on some (correct) entries in /etc/hosts
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: wvdial (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-06 09:26 EST by Johan Walles
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-07 12:02:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Johan Walles 2000-02-06 09:26:59 EST
I have a LAN at home.  The machines are called "johan" (my name) and
"annika" respectively.  Both have a /etc/hosts file looking like this:

"
127.0.0.1	localhost.localdomain	localhost
192.168.0.1	annika.hemma.se	annika  # Annika's computer
192.168.0.2	johan.hemma.se	johan   # Johan's computer
"

My computer contains a modem.  The LAN I dial into uses adresses
172.16.1.*.  Before I set up my own LAN (and gave my machine an IP
address entered in the /etc/hosts file), the Internet connection
worked fine, and the logs showed this after connection:

"
Feb  6 12:14:48 johan pppd[2834]: local  IP address 172.16.1.182
Feb  6 12:14:48 johan pppd[2834]: remote IP address 172.16.1.181
"

After I set up my LAN, the modem dialled out OK, and connected OK, but
I couldn't send or receive any packets to / from the Internet.  The
logs looked like this after connection:

"
Feb  6 12:09:02 johan pppd[653]: local  IP address 192.168.0.2
Feb  6 12:09:02 johan pppd[653]: remote IP address 172.16.1.181
"

I'm not entirely sure how dial-out works in RH61, so the problem may
be with rp3 and not with wvdial, but anyway, this is what I have
found:

Wvdial calls pppd with the "usehostname" parameter.  This I know for
sure, as I got it from the wvdial (1.41) sources.  My guess is that pppd
then resolves my hostname "johan.hemma.se" into 192.168.0.2 and uses that
for my local IP address, instead of letting the remote host decide
(172.16.1.182) for me.

The Internet connection works fine if I remove the "johan.hemma.se"
line from /etc/hosts (but then GNOME complains about not being able to
resolve the hostname on startup).

Whether this is a problem with rp3, wvdial or perhaps pppd I leave for
you to decide.

  Cheers //Johan
Comment 1 Nalin Dahyabhai 2000-02-07 06:39:59 EST
I haven't been able to reproduce this on our test machine.  What you suggest
could only happen if wvdial started pppd, which doesn't happen the way we set
things up (pppd calls wvdial with the --chat flag to have it handle the dialing
only, and the init script that calls pppd doesn't use the usehostname option).

My best guess at this time is that you're seeing a server-side configuration
problem.  If started by the ifup script, pppd will suggest the local hostname's
IP address to the remote end to set up the link.  Try adding "noipdefault" to
your /etc/ppp/options file, which will prevent pppd from doing this.  If that
doesn't solve the problem, please send back the contents of your
/etc/sysconfig/ifcfg-ppp0 and /etc/wvdial.conf files, which may provide a clue
as to what's going on.
Comment 2 Johan Walles 2000-02-07 11:33:59 EST
Your suggested fix of adding noipdefault to /etc/ppp/options solved my problem.
Maybe this should be the default?  Anyway, thanks a bunch.

  Cheers //Johan
Comment 3 Nalin Dahyabhai 2000-02-07 11:58:59 EST
Ack.  I read noipdefault, and though noauth.The noauth option is the default in versions of initscripts from at least 4.70
(the latest errata release) on.  Glad to hear that fixed your problem.
Comment 4 Nalin Dahyabhai 2000-02-07 12:02:59 EST
We're going to add "noipdefault" to the list of default options for the next
release of initscripts, which will go into Raw Hide and future releases.

Note You need to log in before you can comment on or make changes to this bug.