Date: Sat, 19 Dec 1998 21:50:29 +0100 From: "Martin Husemann" <martin@rumolt.teuto.de> To: "Gerhard Sittig" <G.Sittig@abo.FreiePresse.DE> Cc: "FreeBSD-ISDN Mailingliste" <freebsd-isdn@FreeBSD.ORG> Subject: RE: updates to i4b Message-ID: <000101be2b91$363b70b0$53cb08d4@hwart.teuto.de> In-Reply-To: <Pine.LNX.4.02.9812191559280.28352-100000@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
> The solution to this is the dynip > patch (available for Linux, at least) which queues the triggering > packets and resends them with the current IP address after IPCP > negotiation took place. This is not a "solution" but a hack (IMHO), and it's the thing we talked about right at the start of this discussion. There are subtle details, so a bit more discussion before adding this as an optional feature is OK, I think. Never copy linux implementation and call it design before undstanding the problem and all possible solutions and their implications! (No pun intended: this says nothing about either linux implementation or design, just about the "copy an existing implementation" substituting design work.) In the concrete example: the setups where I've met the problem always included some NAT functionality on the ISDN router. Since the local (caching) nameserver as well as the http-client are (at least logicaly) on the other side of the translation, a fine tuned integration between the NAT framework and the IPCP implementation could resolve this problems in a much cleaner way. At least at first lookt this seems possible. Martin 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?000101be2b91$363b70b0$53cb08d4>