Manual dial-up PPP
Kevin Lentin
has me stumped. It can't really be this hard.
I want to configure a dial-up ppp link.
At home, under Linux (no, this isn't an advocacy post, please), I added one
line to /etc/ppp/options, I dial in, I start ppp on the remote end, I
suspect kermit, I type pppd and I live happily ever after. If I felt like
leaving my password on the machine I could put in the dial in script with
one simple change.
I can't under SCO. No matter how I try. I have a dedicated serial line with
PPP running over it and that works fine (it took a week to get it to work
but it works now).
What I want is this (as a start):
I run kermit.
I dial in manually and log into the 'terminal server'
I decide to run PPP (I don't always)
I run ppp on the terminal server,
I suspend kermit (or similar)
I do some magic on the SCO end and the link should appear.
I've tried adding in a 0.0.0.0:0.0.0.0 line into ppphosts but it wants to
do a whole UUCP dialin thing. And even when I persuade it not to do that, I
have no idea how to make PPP start looking at that line that it decided
wasn't wotking at startup time.
I've scoured the manuals, which is difficult as you end up jumping from PPP
to MSTPPP without knowing and there just isn't a single example of this. I
would have thought this would be the most common style of PPP connection as
it's the standard dial-up ISP connection. It's the one things that even
Windows can do with minimum hassle.
Please help.
--
[======================================================================]
[ Kevin Lentin Email: K.Le...@cs.monash.edu.au ]
[ finger kev...@fangorn.cs.monash.edu.au for PGP public key block. ]
[ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ]
[======================================================================]
David Clayton <dclayton@callscan.com.au> 'sco.misc'
> I've been using computers for about 16 years and Unix for 8 or so and this
> has me stumped. It can't really be this hard.
>
> I want to configure a dial-up ppp link.
>
.......
David Clayton <dclayton@callscan.com.au> 'sco.misc'
[SMTP:kev...@cs.monash.edu.au] wrote:
> On Thu, Apr 08, 1999 at 02:31:09PM +1000, David Clayton wrote:
> > This is as clear as mud, do you want an incoming ppp link on the SCO
box or an outgoing one?
>
my
> desire to dial the phone, log in, etc. Unless you were reading it as that
> whole process going on elsewhere _into_ the SCO box. OK, I see how you
> could read it that way, fair enough.
>
> Yes, outgoing. I'm just trying to connect to an ISP from the SCO box.
>
Apparently there is detailed help stuff in the online doco's in your SCO
box, or do a Dejanews search as this question has been answered quite a few
times in the last year.
You should find the answer, or links to where the answer lies.
David C.
Kevin Lentin
> I want to configure a dial-up ppp link.
Although I appreciate all the responses telling me to read the manuals and
search dejanews, that doesn't work. So, I'll post more details here in the
hopes that somebody is willing to actually tell me what is wrong...
I want to establish an outgoing dialup PPP connection to an ISP.
My /etc/ppphosts line looks like this (on 1 line though):
0.0.0.0:0.0.0.0 staticdev=/dev/tty1A speed=57600 mask=255.255.255.0 debug=2
accm =a0000 attach=ISP conf=10
I dial in using kermit, I log in, start the ppp on the remote end, suspend
kermit and type:
pppattach ISP
It outputs one blank line and gives me my prompt back.
syslog has this to say:
Apr 8 16:19:12 thebe pppd[3538]: accept on socket 6
Apr 8 16:19:12 thebe pppd[3538]: pppd_sockread s=7
Apr 8 16:19:12 thebe pppd[3538]: pppattach to 'ISP'
Apr 8 16:19:12 thebe pppd[3538]: ppp_rdstack_cnf: failed to open stack configur
ation file /etc/pppstack, will use defaults
Apr 8 16:19:12 thebe pppd[3538]: can't get passwd for local host
Apr 8 16:19:12 thebe pppd[3538]: getppphostent: no local host ID
Apr 8 16:19:12 thebe pppd[3538]: ppp_rdstack_cnf: failed to open stack configur
ation file /etc/pppstack, will use defaults
Apr 8 16:19:12 thebe pppd[3538]: can't get passwd for local host
Apr 8 16:19:12 thebe pppd[3538]: getppphostent: no local host ID
And that's it.
ifconfig only shows the existing ppp0 connection which already exists
through another serial port on a permanent line.
What is the magic I need to do to make this work?
Scott Roberts
Kevin Lentin wrote in message
<7eh97e$d81$4...@towncrier.cc.monash.edu.au>...
>I've been using computers for about 16 years and Unix for 8 or so and
this
>has me stumped. It can't really be this hard.
It is.
>I want to configure a dial-up ppp link.
>
>At home, under Linux (no, this isn't an advocacy post, please), I
added one
>line to /etc/ppp/options, I dial in, I start ppp on the remote end, I
>suspect kermit, I type pppd and I live happily ever after. If I felt
like
>leaving my password on the machine I could put in the dial in script
with
>one simple change.
>
>I can't under SCO. No matter how I try. I have a dedicated serial
line with
>PPP running over it and that works fine (it took a week to get it to
work
>but it works now).
>
>What I want is this (as a start):
>
>I run kermit.
>I dial in manually and log into the 'terminal server'
>I decide to run PPP (I don't always)
>I run ppp on the terminal server,
>I suspend kermit (or similar)
>I do some magic on the SCO end and the link should appear.
I think this process may be part of your problem. Why do you want to
do the dialing manually? You may have to manually dial when you don't
want PPP, then hang up and re-dial (via pppattach) when you do want
PPP. If you just want shell access to your ISP, couldn't you use
telnet over the PPP link?
>I've tried adding in a 0.0.0.0:0.0.0.0 line into ppphosts but it
wants to
>do a whole UUCP dialin thing. And even when I persuade it not to do
that, I
>have no idea how to make PPP start looking at that line that it
decided
>wasn't wotking at startup time.
I think you may have to let it do the whole UUCP dialin thing.
>I've scoured the manuals, which is difficult as you end up jumping
from PPP
>to MSTPPP without knowing and there just isn't a single example of
this. I
>would have thought this would be the most common style of PPP
connection as
>it's the standard dial-up ISP connection. It's the one things that
even
>Windows can do with minimum hassle.
IMO, you should give MSTPPP a try. There is a graphical configuration
tool that gets you mighty close to a successful link. I played around
with SCOPPP for a while, then installed MSTPPP and got it to work. I'm
not sure one is "better" than the other, but MSTPPP was easier for me
to understand.
HTH,
Scott
Evan Hunt
Don't blame me, I voted for K.Le...@cs.monash.edu.au.
>What I want is this (as a start):
>
>I run kermit.
>I dial in manually and log into the 'terminal server'
>I decide to run PPP (I don't always)
>I run ppp on the terminal server,
>I suspend kermit (or similar)
>I do some magic on the SCO end and the link should appear.
>
>to MSTPPP without knowing and there just isn't a single example of this. I
>would have thought this would be the most common style of PPP connection as
>it's the standard dial-up ISP connection. It's the one things that even
>Windows can do with minimum hassle.
I'm not clear on why you want it to work this way.
I have MSTPPP installed on my system at home. If I want to dial
up direct to the terminal server at work, I can use cu or kermit
to do so. If I want internet connectivity, I can type "telnet
pandora" (that being the name of the box on my desk) and PPP
automagically dials, negotiates with the terminal server, sets up
a default route, and establishes the link in about twenty seconds.
No big hassle. Why do things manually? It's just extra work.
--
Evan Hunt - evanh at sco dot com
"The only thing better than normal, everyday spam is spam from the Lord."
- Jason Abbott
Kevin Lentin
>>I run kermit.
>>I dial in manually and log into the 'terminal server'
>>I decide to run PPP (I don't always)
>>I run ppp on the terminal server,
>>I suspend kermit (or similar)
>>I do some magic on the SCO end and the link should appear.
> I think this process may be part of your problem. Why do you want to
> do the dialing manually? You may have to manually dial when you don't
> want PPP, then hang up and re-dial (via pppattach) when you do want
> PPP. If you just want shell access to your ISP, couldn't you use
> telnet over the PPP link?
True, but I don't want to put my password in the UUCP files. That's just
silly.
Besides, why should it be a problem? I have a dedicated serial link with
ppp operating fine. If I dial up my ISP link, start the remote PPP and then
get rid of kermit, I effectively have exactly the same thing: an existent
serial line with a pppd on the other end waiting for me to talk.
> IMO, you should give MSTPPP a try. There is a graphical configuration
> tool that gets you mighty close to a successful link. I played around
> with SCOPPP for a while, then installed MSTPPP and got it to work. I'm
> not sure one is "better" than the other, but MSTPPP was easier for me
> to understand.
My biggest problem was keeping track of which PPP I was working with. It's
very easy to jump from one to the other without realising.
Kevin Lentin
> No big hassle. Why do things manually? It's just extra work.
Why leave my private passwords on my employer's machine?
Why waste phone calls when a perfectly good serial link exists on which to
run ppp.
Sometimes I like SCO in comparison to Linux which I run at home because SCO
supplies complete products with all the setup scripts and everything.
Sometimes I just want to find the SCO employee who did it and rip vital
organs from their body. We paid over $10,000 for this operating system and
it's pppd is either so stupid or so insane that it can't do something as
simple as start up and talk to a serial port? Either I'm wrong or the world
is very stuffed.
Evan Hunt
>
>Why waste phone calls when a perfectly good serial link exists on which to
>run ppp.
>
>We paid over $10,000 for this operating system and
>it's pppd is either so stupid or so insane that it can't do something as
>simple as start up and talk to a serial port? Either I'm wrong or the world
>is very stuffed.
I didn't say pppd couldn't do it, just that I didn't understand
why you wanted it to. It's designed to bring the link up silently
when you request IP connectivity; I regard that as a good, useful
design. Wanting to manually dial the phone and type your password
every time seems like a hassle, a feature few people would desire.
The fact that you're the first person to ask for this feature in the
three years I've been responsible for MSTPPP on SCO platforms, suggests
that I may have been correct in that evaluation. :)
I can think of two ways to do this. Here's the simpler one: Set
up your modem so it doesn't hang up when it gets an EOF. I forget
how to do that, but there's an AT command sequence that allows it--
perhaps someone else could help out here?
Create a script called "startppp" on the remote side that runs pppd
for you with all the necessary options. Configure MSTPPP on the local
side with no phone number, the specific name of the serial port you'll
be using, and a chat script that just calls "startppp"--something like
this:
1.2.3.4 Any tty1A 115200 N/A "" "" "" startppp
When you want to start up a PPP link, you use kermit to connect to
your modem and dial the phone. Without logging out or entering
"ATH", quit from kermit. The modem should remain connected. Run
pppd with either the "dedicated" or "auto up" option, on that same
serial port. PPP should treat the modem as if it were a fixed serial
link--connect, run "startppp", negotiate with the remote PPP daemon,
and establish a link, without bothering to dial.
I've never tested this, but I can't think why it wouldn't work.
Here's the more complicated way: Write a dialer program, based on
atdialer.c in /usr/lib/uucp, which dials the modem for you. When it
connects, your program should pop up a terminal window so that you can
log in. AFter you've done so, you can close the window, and then your
dialer program would pass control of the terminal back to the calling
process, just as atdialer already does.
Put your new dialer program into /usr/lib/uucp, and put its name
into the first field of /usr/lib/mstppp/Devices. MSTPPP will then
call your program whenever it wants to dial the phone, so you'll get
an opportunity to type your password. The Systems file should look
very much like the other one, except with "ACU" instead of "tty1A".
Tony Lawrence
> I didn't say pppd couldn't do it, just that I didn't understand
> why you wanted it to. It's designed to bring the link up silently
> when you request IP connectivity; I regard that as a good, useful
> design. Wanting to manually dial the phone and type your password
> every time seems like a hassle, a feature few people would desire.
> The fact that you're the first person to ask for this feature in the
> three years I've been responsible for MSTPPP on SCO platforms, suggests
> that I may have been correct in that evaluation. :)
Another reason why someone might want this is when security devices are
used that issue challenges that require entering a variable response
(SecureID, etc.) before allowing your ppp connection. Windows PPP has
always allowed that, but Unix implementations haven't.
--
Tony Lawrence (to...@aplawrence.com)
SCO ACE
SCO articles, help, book reviews: http://www.aplawrence.com
Kevin Lentin
> I didn't say pppd couldn't do it, just that I didn't understand
> why you wanted it to. It's designed to bring the link up silently
> when you request IP connectivity;
Sounds like a dangerous design goal to me. Useful feature yes, but as the
only mode of operation, very limited. I can see my employer being quite
pissed to discover that their system automatically dials into a PPP server
that charges them by the hour when any user types in a bad hostname.
> I regard that as a good, useful
> design. Wanting to manually dial the phone and type your password
> every time seems like a hassle, a feature few people would desire.
On a personal machine maybe. On a machine owned by a client where a
consultant wishes to dial into base when on-site and not leave their
password on said machine? I can't believe it.
> The fact that you're the first person to ask for this feature in the
> three years I've been responsible for MSTPPP on SCO platforms, suggests
> that I may have been correct in that evaluation. :)
I'm amazed. Even Windows has the ability to forget a password. I tend to be
like this. My natural way of using computers is completely contrary to the
way large OS companies think. I spend my life battling against computers.
And so do all the people I went through university with. Except for those
that use them purely as applicaiton platforms where occasionally one person
gets through a day without a complaint. Maybe I'm obtuse, maybe I'm a
one-in-a-million kinda guy, a revolutionary ahead of my time, a complete
idiot? Who knows? I just find it hard to believe that something as simple
as this is impossible from two completely separate PPP implementations.
Time to grab the source for the PPP I'm running on this Linux box and take
it to work. That amazes me.
> I can think of two ways to do this. Here's the simpler one: Set
> up your modem so it doesn't hang up when it gets an EOF. I forget
> how to do that, but there's an AT command sequence that allows it--
> perhaps someone else could help out here?
&D0&C0. Possible. But the standard SCO locking, getty setup will manually
hang up the modem as soon as the dialer/getty discovers nobody is using the
link.
> Create a script called "startppp" on the remote side that runs pppd
> for you with all the necessary options. Configure MSTPPP on the local
> side with no phone number, the specific name of the serial port you'll
> be using, and a chat script that just calls "startppp"--something like
> this:
> 1.2.3.4 Any tty1A 115200 N/A "" "" "" startppp
> When you want to start up a PPP link, you use kermit to connect to
> your modem and dial the phone. Without logging out or entering
> "ATH", quit from kermit. The modem should remain connected. Run
> pppd with either the "dedicated" or "auto up" option, on that same
> serial port. PPP should treat the modem as if it were a fixed serial
> link--connect, run "startppp", negotiate with the remote PPP daemon,
> and establish a link, without bothering to dial.
I would have though that possible. But I've tried and failed. I have
another PPP link working on the machine over an actual dedicated serial
link and I would have imagined that starting the remote pppd, suspending
kermit and then somehow kicking the pppd would be enough. All it needs to
do is, as you say, pretend that tty1A is a fixed port. But it just won't. I
don't know why. I just get that gethostent errot in syslog and nothing
else.
> I've never tested this, but I can't think why it wouldn't work.
Me neither, which is why I asked here :-)
> Here's the more complicated way: Write a dialer program, based on
> atdialer.c in /usr/lib/uucp, which dials the modem for you. When it
> connects, your program should pop up a terminal window so that you can
> log in. AFter you've done so, you can close the window, and then your
> dialer program would pass control of the terminal back to the calling
> process, just as atdialer already does.
Or, of course, the dialer could just exit without doing ANYTHING if the
kermit connection is already up. Good idea.
Kevin Lentin
> Another reason why someone might want this is when security devices are
> used that issue challenges that require entering a variable response
> (SecureID, etc.) before allowing your ppp connection. Windows PPP has
> always allowed that, but Unix implementations haven't.
Not all Unix implementations. Only those that insist on using a chat
script.
Evan Hunt
>> three years I've been responsible for MSTPPP on SCO platforms, suggests
>> that I may have been correct in that evaluation. :)
>
>as this is impossible from two completely separate PPP implementations.
>Time to grab the source for the PPP I'm running on this Linux box and take
>it to work. That amazes me.
It might be less surprising if you take a moment to reflect on
the primary market and the usual mission of the OpenServer platform.
SCO expects this OS to be used most often as a central server
(hence the name), providing gateway functionality, email, web, file
and print services, etc. It's expected to run by itself in a locked
room somewhere; only relatively rarely will users be logged in at
the console. In many if not most cases they won't be logged
in at *all*; they'll be running on windows clients. The vast
majority of them won't be administrators.
It wouldn't be appropriate, in such an environment, to expect any
user to enter the ISP password in order to bring up the internet
connection. That would only make sense for a person running OSr5 as
a desktop workstation, logged in on the console--which is how I run it
and presumably how you do, but it's something of a boundary condition
for the user base as a whole. So I'm not surprised it's never come up
before.
Nonetheless, you've raised some excellent points. I'll look into
adding this feature in a future release.
Tony Lawrence
> It might be less surprising if you take a moment to reflect on
> the primary market and the usual mission of the OpenServer platform.
> SCO expects this OS to be used most often as a central server
> (hence the name), providing gateway functionality, email, web, file
> and print services, etc. It's expected to run by itself in a locked
> room somewhere; only relatively rarely will users be logged in at
> the console. In many if not most cases they won't be logged
> in at *all*; they'll be running on windows clients. The vast
> majority of them won't be administrators.
If that's how SCO thinks the majority of its products are used, then
somebody needs a giant clue pill.
-
Kevin Lentin
> It wouldn't be appropriate, in such an environment, to expect any
> user to enter the ISP password in order to bring up the internet
> connection. That would only make sense for a person running OSr5 as
> a desktop workstation, logged in on the console--which is how I run it
> and presumably how you do, but it's something of a boundary condition
> for the user base as a whole. So I'm not surprised it's never come up
> before.
I'm not using it as a desktop workstation. It's our server. I just have the
occasionaly need to make it connect to an ISP.
What I find annoying is that what I want to do is almost identical to
something I'm already doing.
ie:
hyperion:thebe-hyperion staticdev=/dev/tty1f00 speed=9600 mask=255.255.255.0 debug=1 accm=a0000
works fine. tty1f00 is a permanent serial connection to another state.
There's no dialing.
Now I add this:
0.0.0.0:0.0.0.0 staticdev=/dev/tty1A speed=57600 mask=255.255.255.0 debug=2 accm=a0000
And it doesn't work. It should. I've established the tty1A connection using
kermit so from its point of view 1A and 1f00 are identical. So it's the fact
that one is dynamic and one isn't that is causing the problem.
So somebody at SCO must have written explicit code to stop the second case
working. Maybe.
That makes no sense to me. Why remove a feature just because you don't
believe somebody might use it?
And I should point out to the person who said I was the first person to
want this, that I currently have about 4 people in my inbox waiting for the
solution to this exact problem should I ever find it.
So far one person has actually been able to answer the question of what the
'getppphostent: no such host ID' message was all about but even that
doesn't look like helping.
> Nonetheless, you've raised some excellent points. I'll look into
> adding this feature in a future release.
It appears to me that SCO PPP treats all of its different kinds of links as
totally different beasts instead of variants on a theme.
Some links use static devs, some let the system choose, some dial some
don't, some use dynamic IP addresses, some static. Yet all the manpages
talk about different kinds of links as if they are implemented separately.
Seems like a waste of code if that is the case. Just step through the
process doing what needs to be done. If you need to dial, you dial,
otherwise just skip it. If you need to negotitate IP addresses, choose the
right negotiation technique and go for it, or not.
Kevin Lentin
> If that's how SCO thinks the majority of its products are used, then
> somebody needs a giant clue pill.
I gave up on VisionFS for that reason. I spent 3 whole days trying to get
printing working (it wouldn't in one direction or the other and as far as I
can tell there are no instructions ANYWHERE on how to make it so) and
eventually installed Samba and had it working flawlessly in 20 minutes.
What annoyed me the most was that I _HAD_ to configure a Unix product from
a PC. I couldn't do it from a root login on the server. I couldn't do it
from off site via a dialup.
It's part of what seems like a general attitude towards the software. Make
it as 'powerful' as possible and then remove all flexibility. What you end
up with is something that does certain things extremely well and extremely
robustly with cool config scripts and anything. But if you want to use
something in anything other than the way SCO intended you to, you're
stuffed. I far prefer software that is as configurable as all hell, a
jack-of-all-trades if you will so I can make it do what I want when I want
it to. The config scripts can still provide the standard setups easily for
the closed fisted admins out there but you end up with a far more powerful
product.
It's just a different attitude to software design. I'm having the exact
same argument with a supplier of scan-packing software. They design the
software around the retail theory of scan packing except the retail world
wouldn't have a clue how things really work and it's currently costing us
money to contort our warehouse practices into the most horrendously
non-productive system you could imagine. I ask them to add features and
they say that might confuse some people or force _them_ to change the way
they work. I say, make it a config option, they say too many config options
makes it too complicated - but they're the ones installing it. It just
makes no sense to me.
When I sit and extract specs from the people around here, I prod them with
future possibilities and in the end design things so that things can change
in the future or add options in all over the place which are either always
on or off because I know, one day, they'll change their minds. And they
invariably do. And when I say the software can already do that, they ask me
why and I tell them that I told them they would want to when we spec'ed it
and they said no. So for 1% extra work, they get 100% extra product.
But, as I have said in this thread before, I don't seem to be normal.
Joseph M. Bironas
wrote:
>I gave up on VisionFS for that reason. I spent 3 whole days trying to get
>printing working (it wouldn't in one direction or the other and as far as I
>can tell there are no instructions ANYWHERE on how to make it so) and
>eventually installed Samba and had it working flawlessly in 20 minutes.
>
>What annoyed me the most was that I _HAD_ to configure a Unix product from
>a PC. I couldn't do it from a root login on the server. I couldn't do it
>from off site via a dialup.
Not to disagree with what you are saying about VisionFS being flawed,
because it most certainly is, but you don't *have* to cinfigure it
from a PC, although that is the most visible form of configuaration.
If you log into the server as root and go to /usr/local/vision/bin (if
I recall correctly) then you will see an executable called vision-fs
that you can pass administrative commands. Works like a charm for me
since VisionFS is always crashing and breaking the link to the PC app.
>It's part of what seems like a general attitude towards the software. Make
>it as 'powerful' as possible and then remove all flexibility. What you end
I believe that they are now calling this "User Friendly"
>It's just a different attitude to software design. I'm having the exact
>same argument with a supplier of scan-packing software. They design the
>software around the retail theory of scan packing except the retail world
>wouldn't have a clue how things really work and it's currently costing us
>money to contort our warehouse practices into the most horrendously
>non-productive system you could imagine. I ask them to add features and
>they say that might confuse some people or force _them_ to change the way
>they work. I say, make it a config option, they say too many config options
>makes it too complicated - but they're the ones installing it. It just
>makes no sense to me.
Unfortunately I think I work for the company you are describing... (at
least one that sucks every bit as bad)
>and they said no. So for 1% extra work, they get 100% extra product.
>
>But, as I have said in this thread before, I don't seem to be normal.
Good for you...
Evan Hunt
>working. Maybe.
SCO PPP isn't my bailiwick, MST PPP is--but I doubt anything was actually
deliberately broken. I'm not even sure how it could have been. From the
standpoint of wires and signals, is it even possible to tell the difference
between a hard serial connection and a connection to an active modem?
If so, how is it different?
>And I should point out to the person who said I was the first person to
>want this, that I currently have about 4 people in my inbox waiting for the
>solution to this exact problem should I ever find it.
Thanks for mentioning that; it'll be useful if I have to justify doing
work on this.
Kevin Lentin
> Not to disagree with what you are saying about VisionFS being flawed,
> because it most certainly is, but you don't *have* to cinfigure it
> from a PC, although that is the most visible form of configuaration.
> If you log into the server as root and go to /usr/local/vision/bin (if
> I recall correctly) then you will see an executable called vision-fs
> that you can pass administrative commands. Works like a charm for me
> since VisionFS is always crashing and breaking the link to the PC app.
There were a few files I found that looked like config files but they made
sendmail.cf look tame by comparison. Being able to send commands is good
but when you're installing it for the first time, you really want a config
file and a manual to explain the simple entries in it. Sorta like Samba :-)
> I believe that they are now calling this "User Friendly"
Because the user has no choice
Kevin Lentin
> SCO PPP isn't my bailiwick, MST PPP is--but I doubt anything was actually
> deliberately broken. I'm not even sure how it could have been. From the
> standpoint of wires and signals, is it even possible to tell the difference
> between a hard serial connection and a connection to an active modem?
> If so, how is it different?
I wish I knew. All I know is that I can't do it and nobody here knows how
to make it work. I think the answer is that SCO PPP will not do dynamic IP
addresses over a fixed serial port. Who knows why?
> Thanks for mentioning that; it'll be useful if I have to justify doing
> work on this.
No problem. Evan, you seem to be quite deeply involved so I would
appreciate if you could check my hypothesis above. ie that a
0.0.0.0:0.0.0.0 link MUST use uucp dialup but a 1.2.3.4:1.2.3.5 link does
not. Because that seems to be my conclusion here.