'iijppp -auto' and Dynamic IP Address Allocation

'iijppp -auto' and Dynamic IP Address Allocation

Post by Pierre Y. Dampur » Tue, 11 Jun 1996 04:00:00



How can one set up iijppp to get dial on demand when one's ISP
allocates from either a class B or class C network ? seems Pipex
allocates its dialup IP clients either in net 128.43 or in net
193.130.250, which makes it rather difficult for iijppp to deal with !

I probably miss something, but has anyone successfully implemented
iijppp dial on demand with this ISP ?

ThanX in advance,

Pierre Y. Dampure

"Et les shadocks pompaient, pompaient..."

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by Ken Bigelo » Tue, 11 Jun 1996 04:00:00



> How can one set up iijppp to get dial on demand when one's ISP
> allocates from either a class B or class C network ? seems Pipex
> allocates its dialup IP clients either in net 128.43 or in net
> 193.130.250, which makes it rather difficult for iijppp to deal with !

> I probably miss something, but has anyone successfully implemented
> iijppp dial on demand with this ISP ?
> Check the handbook on user PPP, and also look through all of the sample

ppp.--- files in /etc/ppp. It is quite possible to have iijppp accept
either or both IP addresses from the peer.

The basic procedure is to allocate an IP address of 0.0.0.0/0, and let
the negotiations take place normally. This technique is included in the
sample files.

I hope this helps!

Ken

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by Pierre Y. Dampur » Tue, 11 Jun 1996 04:00:00




> > How can one set up iijppp to get dial on demand when one's ISP
> > allocates from either a class B or class C network ? seems Pipex
> > allocates its dialup IP clients either in net 128.43 or in net
> > 193.130.250, which makes it rather difficult for iijppp to deal with !

> > I probably miss something, but has anyone successfully implemented
> > iijppp dial on demand with this ISP ?
> > Check the handbook on user PPP, and also look through all of the sample
> ppp.--- files in /etc/ppp. It is quite possible to have iijppp accept
> either or both IP addresses from the peer.

> The basic procedure is to allocate an IP address of 0.0.0.0/0, and let
> the negotiations take place normally. This technique is included in the
> sample files.

> I hope this helps!

> Ken

I'm afraid this will not work straight out of the box, Ken. I did a bit
of digging around your tip, however, and found a somewhat acceptable
solution :

        set ifaddr 0 158.43.128.1/0

Indeed, your straight

        set ifaddr 0 0

causes ijppp to come up with a 'must specify dtsaddr in auto mode'
message and to abort -- I guess it must find itself in some kind of
chicken and egg situation.

The downside of the above cheat is, I now need to ping the dummy dstaddr
once to get the ball rolling -- I mean, the proper route installed --
easily done in rc.local, but I'd rather do without.

Is this where diald starts looking like a reasonable alternative ?

Pierre Y.

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by J Wuns » Tue, 11 Jun 1996 04:00:00



Quote:> How can one set up iijppp to get dial on demand when one's ISP
> allocates from either a class B or class C network ? seems Pipex
> allocates its dialup IP clients either in net 128.43 or in net
> 193.130.250, which makes it rather difficult for iijppp to deal with !

It's impossible.  Demand-dialing requires a fixed IP address to be
assigned for the remote end.  If you think about how routing works,
you will know why it must be this way.  (You're running into a
chicken-and-egg problem otherwise.)

--
cheers, J"org


Never trust an operating system you don't have sources for. ;-)

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by J Wuns » Tue, 11 Jun 1996 04:00:00



> The basic procedure is to allocate an IP address of 0.0.0.0/0, and let
> the negotiations take place normally. This technique is included in the
> sample files.

You cannot autodial on this however.  This is quite clear if you think
about how autodialing works -- it must detect an outgoing packet
destined for a particular address before, in order to know that it has
to dial just for this packet now.

--
cheers, J"org


Never trust an operating system you don't have sources for. ;-)

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by Rahul Dhes » Wed, 12 Jun 1996 04:00:00



[ how to do dial on demand when IP addresses are unknown ]

Quote:>It's impossible.  Demand-dialing requires a fixed IP address to be
>assigned for the remote end.  If you think about how routing works,
>you will know why it must be this way.  (You're running into a
>chicken-and-egg problem otherwise.)

Actually I believe this is an implementation issue.  If the 'default'
entry in your routing table must point to a specific IP address, then
you have the above problem.

But what if you add a static 'default' route pointing to the point-to-point
device?  If your kernel is appropriately coded, such a default route does not
need a gateway IP address.  It simply means 'packets destined for unknown IP
addresses should be sent this way'.  There is only one device at the other end
of the point-to-point link, so we don't care what its IP address is.

Once you implement this, automatic dial-out becomes easy.  Just begin dialing
if (a) the point-to-point link is not up and (b) we receive a packet that
needs to go out tht way.

Here, for example, is part of an actual routing table from an Onramp router:

Dest            Len Interface Gateway          Metric  P Timer   Hits    Use
204.095.070.183 32  en0       204.095.064.002  2         239     2085   1465
default         0   syn0                       1         0     23490132 22454384

Notice that one route (pointing towards the Ethernet port) specifies a
gateway -- because on a LAN one needs a MAC address to send the packet to, and
we get this by first knowing the IP address of the gateway.  However, the
default route points to the syn0 device, which is connected to a point-to-point
link.  No gateway IP address is needed, because we have no coice:  there can
only be one device at the other end of the point-to-point link.

A LAN is like a highway with many exits.  You need to know which one to take.
A point-to-point link is like a well down which you jump.  You have not much
choice, once you have jumped, about where to go...
--


 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by Pierre Y. Dampur » Wed, 12 Jun 1996 04:00:00



> You cannot autodial on this however.  This is quite clear if you think
> about how autodialing works -- it must detect an outgoing packet
> destined for a particular address before, in order to know that it has
> to dial just for this packet now.

Jorg,

Your point certainly makes sense, hence my experiments with a "false
real" address /all bits variable; as mentioned, it worked that way.

In /etc/ppp/ppp.conf :

        set ifaddr 0 x.y.z.t/0
        add 0 0 x.y.z.t

In /etc/ppp/ppp.linkup :

        MYADDR:
          delete ALL
          add 0 0 HISADDR

In /etc/rc.local

        ppp -auto pipex

The first 'add' (in ppp.conf) fools the kernel into believing x.y.z.t is
the proper end of the link; the 'delete ALL' get read of this fake when
the link comes up, and the second 'add' establishes the proper end.

I suspect x.y.z.t could be any address (like one picked from the
"non-connected" network address space) -- I just used the address of one
of the pads I connected to, but I ended up with enough different ones to
prove this worked.

There is however a slight problem : the 'delete ALL' does not seem to
get rid of the routing entry between the OLD local address and 127.0.01,
which means the routing table fills in with junk entries after a number
of connect/disconnect. In fact, what we need is a ppp.linkdown, so that
we could delete these junk entries automatically when the connection
goes down.

I must point out (me being a newbie, that should be obvious) that I did
not try any of these with gated. I dread to think what's gonna happen if
I ever do !

Salutations Distinguees,

Pierre Y.

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by Tim Ivers » Wed, 12 Jun 1996 04:00:00




|
|[ how to do dial on demand when IP addresses are unknown ]
|
|>It's impossible.  Demand-dialing requires a fixed IP address to be
|
|Actually I believe this is an implementation issue.  If the 'default'
|But what if you add a static 'default' route pointing to the point-to-point
|device?  If your kernel is appropriately coded, such a default route does not
|need a gateway IP address.  It simply means 'packets destined for unknown IP

The link is point-to-point once it's established, but before the link is up,
it's essentially point-to-multiple; you don't have to dial the same number
every time.  I've been thinking about giving up on iijppp just 'cuz of it's
limited routing and dialing.  With pppd, you can use perl, xchat, basically
any other tool around to help detect, establish, and maintain a link.

Unfortunately, pppd has very poor debug output compared to iijppp.  It's
pretty simple to get iij to work, but so far, pppd always fails for me with
'timeout during LCP'.  If it displayed both ends of the conversation, it
would probably be a snap to fix, but that's all it says.

- Tim Iverson

 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by James Rayna » Thu, 13 Jun 1996 04:00:00




>Unfortunately, pppd has very poor debug output compared to iijppp.  It's
>pretty simple to get iij to work, but so far, pppd always fails for me with
>'timeout during LCP'.  If it displayed both ends of the conversation, it
>would probably be a snap to fix, but that's all it says.

Use the -d option and add the line

daemon.debug                                    /var/log/debug

to /etc/syslog.conf.

(Note:- you'll have to send a SIGHUP to syslogd to make it re-read its
config file, and the gap between 'daemon.debug' and '/var/log/debug'
must consist of tabs only - no spaces).

--
James Raynard, Edinburgh, Scotland


 
 
 

'iijppp -auto' and Dynamic IP Address Allocation

Post by Tim Ivers » Fri, 14 Jun 1996 04:00:00




|>
|>Unfortunately, pppd has very poor debug output compared to iijppp.  It's
|
|Use the -d option and add the line
|
|daemon.debug                                    /var/log/debug
|
|to /etc/syslog.conf.
|
|(Note:- you'll have to send a SIGHUP to syslogd to make it re-read its
|config file, and the gap between 'daemon.debug' and '/var/log/debug'
|must consist of tabs only - no spaces).

I had already tried this.  Doesn't help.  I might make another go at it this
weekend.  If it's a real problem and not just something stupid that I did,
I'll post the results here ... ;-)

- Tim Iverson

 
 
 

1. Dynamic IP address and 'r' commands?


Unfortunately, you're probably screwed.  Unless your ISP has some
arrangement to always assign the same name to the address they've assigned
to you (most don't -- they just have a unique name that's permanently
associated with each dialup address), there's nothing you can put in your
.rhosts file that will work well.

Before someone suggests something like dyndns.com, I've already thought of
that.  The problem is that those services only implement forward DNS.  The
r-command servers generally use reverse DNS -- they translate the client
address to a name and then check the .rhosts file to see if the name is in
there.  Reverse DNS is controlled by the ISP, not the dynamic DNS provider.

--

GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

2. What is this DING! thing?

3. 'Static Hostnames' while having a dynamic IP address

4. finger tells me "never logged in" ? how to fix it?

5. DIP patch (dynamic IP address trapping, route 'default' option)

6. Find and replace

7. Help needed: dynamic ip addresses - iijppp on FreeBSD

8. mail lock

9. Will changing IP address affect 'rlogin'/'telnet'?

10. Auto PPP using PAP + Static+Dynamic IP's?

11. Route by IP address over tun0 - 'ip rule add from a.b.c.d'

12. Is different 'Ethenet address' from 'Mac Address' ?