Bug 17968 - isdn auto dial doesn't work
Summary: isdn auto dial doesn't work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: isdn-config   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-09-30 19:36 UTC by Paul Flinders
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-11 13:31:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Paul Flinders 2000-09-30 19:36:31 UTC
Using isdn-config and selecting dialmode=auto  is a somewhat disappointing

Initially having started ISDN trying to browse the redhat site produced an
error dialog from Netscape saying "Netscape is unable to find the server

A bit of thought and quick check of /etc/resolv.conf shows why; there
were no nameservers configured so no packet will get as far as the ippp
device to trigger dialling because the resolver library will reject the
name lookup before then.

If a DNS server is specified then ipppd is run with the ms-dns option
which I think is wrong. The documentation says that you are supplying
the ISP's DNS server but the ms-dns option to ipppd is to support in-
bound MS-Windows clients

Surely isdn-config should fill in /etc/resolv.conf if you supply a DNS
(and being able to supply more than one would be useful). If you don't
know the ISP's DNS server perhaps a "well known" DNS server could be
substituted until the ISP's server is known. Ultimately I suppose the
solution is to change the resolver library so that it could trigger
dialling and
try to discover a DNS server if there are no nameservers listed but dns
is in /etc/nsswitch.conf for host resolution

OK, so edit /etc/resolv.conf and add a handy DNS server - as it happens
my employers rather than my ISPs (I use more than one ISP so my employer
is a useful "neutral" DNS server), everything works.

Now hangup and try again - this time I get a "Network is unreachable" error
from Netscape.

The problem now is that the default route gets removed when the interface
goes down (the network routes to the other end of the PPP link remain) so
although I know where to do the DNS query I have no route to the server.

Ideally the routing should be restored to the pre-dial state by the ifdown
scripts. Leaving the route to the network corresponding to the remote
ppp address seems pointless, not re-instating the default route through
a ppp device means that an outgoing packet will not get far enough to
trigger auto-dial.

Comment 1 Ulrich Sibiller 2000-10-04 14:23:03 UTC
> if you supply a DNS server (and being able to supply more than one would be
> useful)

You _can_ provide more than one DNS by entering them in the DNS field, separated
by spaces!

Comment 2 Ngo Than 2000-11-02 13:25:01 UTC
It's fixed in isdn-config-0.18-3. You will find it in rawhide soon.

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