Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?000101be2b91$363b70b0$53cb08d4>