From owner-freebsd-isdn Sat Dec 19 12:56:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16983 for freebsd-isdn-outgoing; Sat, 19 Dec 1998 12:56:16 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from linteuto.teuto.de (linteuto.teuto.de [194.77.23.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA16976 for ; Sat, 19 Dec 1998 12:56:12 -0800 (PST) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [212.8.203.81]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id VAA29006; Sat, 19 Dec 1998 21:56:09 +0100 Received: from hwart (hwart.teuto.de [212.8.203.83]) by rumolt.teuto.de (8.8.8/8.8.7) with SMTP id VAA01258; Sat, 19 Dec 1998 21:50:30 +0100 (MET) From: "Martin Husemann" To: "Gerhard Sittig" Cc: "FreeBSD-ISDN Mailingliste" Subject: RE: updates to i4b Date: Sat, 19 Dec 1998 21:50:29 +0100 Message-ID: <000101be2b91$363b70b0$53cb08d4@hwart.teuto.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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