Date: Tue, 24 Nov 1998 10:02:06 +0100 (CET) From: Malte Lance <malte.lance@gmx.net> To: G.Sittig@abo.FreiePresse.DE Cc: malte.lance@gmx.net, freebsd-isdn@FreeBSD.ORG Subject: Re: isppp + dynamic IP Message-ID: <199811240902.KAA04341@neuron.webmore.prv> In-Reply-To: <Pine.LNX.4.02.9811232207280.26917-100000@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Nov, Gerhard Sittig wrote: > 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. Right ... my fault ... sorry. > > 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 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. 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. > 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. ["ifconfig isppp0 down" hangs up the line] > > 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. Haeeee ??? That's what i was trying to tell ... maybe in a somewhat confusing way. 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" The implication is of course that the packets with src-adr 0.0.0.0 never get back to the sender. > > 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. What unknown hosts at boottime ??? I set up a hosts-file where all lookups for hosts that need to be looked up at boottime are resolved. No need to ask bind. I wonder how there could be unknown hosts at boottime. Don't get me wrong please ... there are of course some DNS-names that need to be looked up at boottime, but as i said, this is easily solvable with /etc/hosts > >> 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 :) Good enough for you (tm) ;) What about proxies/caches (WWW/FTP/...) ? Malte. > > > G.Sittig@abo.FreiePresse.DE -- Malte Lance. --- composed with TkRat 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?199811240902.KAA04341>