Date: Mon, 23 Nov 1998 22:34:16 +0100 (CET) From: Gerhard Sittig <G.Sittig@abo.FreiePresse.DE> To: Malte Lance <malte.lance@gmx.net> Cc: FreeBSD-ISDN Mailingliste <freebsd-isdn@FreeBSD.ORG> Subject: Re: isppp + dynamic IP Message-ID: <Pine.LNX.4.02.9811232207280.26917-100000@speedy.gsinet> In-Reply-To: <199811231546.QAA00687@neuron.webmore.prv>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for butting in, but ...
First of all you should make clear who wrote which parts of the
text you're citing. The ones indented twice (now three times)
are mine.
On Mon, 23 Nov 1998, Malte Lance wrote:
> On 22 Nov, Marc van Woerkom wrote:
> >
> >> When the connection goes up
> >> the ISDN interface has ANY address and sends out its first packet.
> >> While negotiating with the ISP the interface CHANGES its address to
> >> the newly assigned one and won't accept the answer for the first sent
>
> Wrong. The first outgoing packet on a dynamic-IP interface never
> gets back. Read on.
Picture something like this:
Upon boot I do a (somewhat simple) setup:
ifconfig ippp0 inet 192.168.13.254 pointopoint 10.10.10.1 up
route add default dev ippp0
Whenever there's a packet for a nonlocal address it will get
192.168.13.254 as the sender's address and since it's the first
one for the interface it triggers dialing. Upon negogiation
ipppd does something like
ifconfig ippp0 down
ifconfig ippp0 inet $MYDYNIP pointopoint $HISDYNIP up
route add default dev ippp0
then the packet DOES go out to the world, carrying a wrong
address. THAT'S why the dynip patch resends the packet after
filling in the newly assigned address.
The same holds true for hanging up and redialing -- there's a
queued packet with a wrong address and a reconfigured interface.
I wouldn't dare to assume 0.0.0.0 for all the cases :) And to
make it clear once more: It's the ANSWER that will be dropped
or misrouted (wrt what one might expect as the dialer) not the
triggering packet.
BTW: setting up the ISDN interface at boot time will save you
from DNS lookups due to unknown hosts when quickly typing 'route'
omitting the -n switch. This is also valid when you "reset" the
ISDN interface upon hangup to the setup after boot.
> some clients, take telnet for example, are bound for the whole
> session after calling connect(). That means the session is bound
> to 0.0.0.0 on the local side when the connect() returns prior to
> the link getting established.
That's quite another problem, but it never puzzled me since it
doesn't apply to routers and firewalls -- they just forward their
packets and don't serve as a source for telnet sessions :)
G.Sittig@abo.FreiePresse.DE
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.02.9811232207280.26917-100000>