Date: Wed, 25 Nov 1998 01:24:49 +0100 (CET) From: Gerhard Sittig <G.Sittig@abo.FreiePresse.DE> To: Malte Lance <malte.lance@gmx.net> Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: isppp + dynamic IP Message-ID: <Pine.LNX.4.02.9811242325080.27943-100000@speedy.gsinet> In-Reply-To: <199811240902.KAA04341@neuron.webmore.prv>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Nov 1998, Malte Lance wrote:
> On 23 Nov, Gerhard Sittig wrote:
>
> Wait a minute ...
>
> ... were we talking about dynamic-assigned local IP-addresses
> on the interface ???
>
> I was under that impression.
> If you were talking about something else, then sorry, ... i missed
> the topic.
> Otherwise:
> dynamic-assigned IP-addresses are configured with isdn4bsd by
> assigning 0.0.0.0 as the local address on the isdn-interface.
> When assigning some other address as the local part to the interface,
> the sppp-code insists on getting exactly that address from the peer.
> If the peer does not agree on that, IPCP does not come up.
Oh, sorry. Since ISDN support is somewhat new in FreeBSD (at least
in its current form of i4b, I don't know much about the previous
version since it didn't work for me) I have been using linux for
some years now. And since one doesn't touch a running system
without any strong need I have to admit I never had any further
tests with ISDN under BSD since i4b came up. I just follow these
lists (announce and freebsd-isdn) because one day i MIGHT want to
change to BSD at least on the serving machines (that should be
transparent for anyone since I won't touch any workstation). So
I beg your pardon for my ignorance for the internals and details.
To cut it short: I didn't know about that convention since in Linux
you can setup your interfaces however you please and ipppd (a derivate
of pppd) reconfigures your interface in case IPCP negotiation did
take place (of course you can configure whether you accept these or
assume a fix setup).
> Some months ago i've written the changes to the sppp-code to enable
> dynamic-IP-adr-assignment by just giving spppcontrol a command-line-
> flag, instead of setting the local address to 0.0.0.0. So you got
> the freedom to set it to any local IP-address without disabling the
> dynamic-IP-address-assignment. Since nobody on this list was really
> interested in the changes, i did not bother Hellmuth with the patches.
That's what i4l does by default. So you have configured interfaces
with IP addresses you have to be able to resolve in reverse queries
when issuing commands like "netstat" and "route". And once you
were dialing up to your ISP and hanging up you have an address
assigned to an interface you don't know (unless you run a local
named). That's when "normal" commands trigger another dialup
due to the DNS query, you get this answer, but you then own a
different address which you again don't know and start it over
again and again and ...
Given the prices here in Germany this really is annoying AND
expensive, too.
> > 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
>
> ["ifconfig isppp0 down" hangs up the line]
The above was pseudo code to demonstrate the behaviour of ipppd
and why previous routes through this interface get lost (and have
to be reestablished by a hooked in script upon ip-up and ip-down).
> Here is what i said:
> "In short, until the interface has not been assigned
> the dynamic IP-adr, the outgoing packets get a source-IP
> of 0.0.0.0"
Now that you corrected my mistake we DO agree here :)
> >> [ ... tcp sessions bound to obsolete address ... ]
> >
> > 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 :)
>
> Good enough for you (tm) ;)
> What about proxies/caches (WWW/FTP/...) ?
That's the kind of software i DON'T run on firewalls :) In general
I don't do ANYTHING there besides ssh from the internal LAN for
administrative purposes. And while I feel that ANY network should
protect its dialup connection I don't see a need for dialups doing
a TCP session originating from themselves.
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.9811242325080.27943-100000>