> Brian Somers schrieb:
> > 
> > > Hi,
> > >
> > > after the latest updates I just noticed a different behaviour of ppp.
> > >
> > > in /etc/ppp/ppp.linkup I had an additional line
> > >   iface clear
> > > for my profile to get rid of stuffed up IP pairs. After the latest update
> > > this entry also clears my defaultroute, but only after redialing.
> > >
> > > I now had to put the "iface clear" into /etc/ppp/ppp.linkdown, but then
> > > the old IP pair is still there during the next connection.
> > 
> > Putting ``iface clear'' in ppp.linkup will result in the whole
> > iface-alias thing being broken.  It's meant to be in ppp.linkdown.
> > 
> > The objective is that ppp, once connected, has two IP numbers on the
> > interface, one for what was there before the connection completed and
> > one for the negotiated IP address.  When this happens, the ``first
> > connection'' continues to work (the process that caused the dial-up
> > will be bound to the IP number that was on the interface when it
> > started and the nat engine will tweak these packets so that they use
> > the negotiated IP number).
> Suppose on the first connection I got the IP pair
> A <-> B
> and on the second
> C <-> D
> while the second one still active another person will get
> A <-> B
> assigned by our ISP.
> Will I be able to talk with A or B? Or will they point back to myself?
> I put the "iface clear" in ppp.linkup for exactly this case.

Say for example that you do ``set ifaddr A B'' and then 
``telnet X'' when the link is down.  telnet does a connect(X), 
resulting in a local binding to address A with a destination address 
of X.

ppp brings the link up and negotiates C <--> D, but keeps A <--> B on 
the interface.

The initial ``telnet X'' packet (A --> X) can now be transmitted, 
but ppp's alias address is now C.  It NATs the packet to C --> X and 
sends it out.  X gets it and sends a packet back to C.  Your ISP 
routes to C correctly and your ppp process unNATs it back to A.

Thus your ``first connection'' works when in reality it should not.

If you ``iface clear'' on linkup, ppp doesn't NAT the A --> X packet 
and X replies to A -- which your ISP (of course) can't route.

> > So really, you're doing the equivalent of ``disable iface-alias'' and
> > stopping your first connection from working.  Moving the ``iface
> > clear'' to ppp.linkdown should be better.
> > 
> > > Were my assumptions wrong (regarding the "iface clear" command) or is
> > > something
> > > broken in ppp?
> > 
> > Yes and yes.
> Hmm, I didn't notice any problems before the last commit... Any automatic
> connection (even the first) worked without any problems.

That may be because most connections consist of a DNS lookup 
followed by the connect... but I'm not sure about that.

> But: iface clear just went from ppp.linkdown to ppp.linkup some weeks
> ago, but after I got DSL. With DSL the destination IP address is always
> the same.
> I don't know if this configuration would work with my old ISDN access with
> changing destination IP addresses.

It should work ok now.  Adding an interface address only needs to 
special-case things when either the source or destination addresses 
conflict with ones that are already assigned to the interface.

> -- 
> Daniel

Brian <[EMAIL PROTECTED]>                <[EMAIL PROTECTED]>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to