Mention that the ``first connection'' problem is fixed in the

latest version of ppp.
This commit is contained in:
Brian Somers 1998-10-22 18:14:54 +00:00
parent c904464fff
commit 0d7ea4b7ce
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=3655

View file

@ -1,4 +1,4 @@
<!-- $Id: network.sgml,v 1.15 1998-09-06 13:55:10 brian Exp $ --> <!-- $Id: network.sgml,v 1.16 1998-10-22 18:14:54 brian Exp $ -->
<!-- The FreeBSD Documentation Project --> <!-- The FreeBSD Documentation Project -->
<sect> <sect>
@ -715,9 +715,12 @@ default 10.0.0.2 UGSc 0 0 tun0
The process that forces a dial in auto mode never connects The process that forces a dial in auto mode never connects
</heading> </heading>
<p>This is a known problem when <bf/ppp/ is set up to negotiate <p>This was a known problem with <bf/ppp/ set up to negotiate
a dynamic local IP number with the peer. When that initial program a dynamic local IP number with the peer in auto mode. It is
calls <htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect" fixed in the latest version - search the man page for <bf/iface/.
<p>The problem was that when that initial program calls
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
name="connect(2)">, the IP number of the tun interface is name="connect(2)">, the IP number of the tun interface is
assigned to the socket endpoint. The kernel creates the first assigned to the socket endpoint. The kernel creates the first
outgoing packet and writes it to the tun device. <bf/Ppp/ then outgoing packet and writes it to the tun device. <bf/Ppp/ then
@ -730,22 +733,27 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>There are several theoretical ways to approach this problem. <p>There are several theoretical ways to approach this problem.
It would be nicest if the peer would re-assign the same IP number It would be nicest if the peer would re-assign the same IP number
if possible <tt/:-)/ if possible <tt/:-)/ The current version of <bf/ppp/ does this,
but most other implementations don't.
<p>The easiest method from our side would be to never change the <p>The easiest method from our side would be to never change the
tun interface IP number, but instead to change all outgoing packets tun interface IP number, but instead to change all outgoing packets
so that the source IP number is changed from the interface IP to so that the source IP number is changed from the interface IP to
the negotiated IP on the fly. This is essentially what the negotiated IP on the fly. This is essentially what the
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias" <tt/iface-alias/ option in the latest version of <bf/ppp/ is
name="libalias(3)"> (and ppp's <bf/-alias/ switch) already does. doing (with the help of <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?libalias" name="libalias(3)">
and ppp's <bf/-alias/ switch) - it's maintaining all previous
interface addresses and aliasing them to the last negotiated address.
<p>Another alternative (and probably the most reliable) is to <p>Another alternative (and probably the most reliable) would be
implement a system call that changes all bound sockets from one to implement a system call that changes all bound sockets from one
IP to another. <bf/Ppp/ would use this call to modify the IP to another. <bf/Ppp/ would use this call to modify the
sockets of all existing programs when a new IP number is sockets of all existing programs when a new IP number is
negotiated. negotiated. The same system call could be used by dhcp clients
when they are forced to re-bind() their sockets.
<p>A third possibility is to allow an interface to be brought <p>Yet another possibility is to allow an interface to be brought
up without an IP number. Outgoing packets would be given up without an IP number. Outgoing packets would be given
an IP number of 255.255.255.255 up until the first SIOCAIFADDR an IP number of 255.255.255.255 up until the first SIOCAIFADDR
ioctl is done. This would result in fully binding the socket. It ioctl is done. This would result in fully binding the socket. It
@ -756,8 +764,6 @@ default 10.0.0.2 UGSc 0 0 tun0
configured interface, on the assumption that some other mechanism configured interface, on the assumption that some other mechanism
is capable of fixing things retrospectively. is capable of fixing things retrospectively.
<p>None of these solutions has been implemented (yet).
<sect2> <sect2>
<heading>Why don't most games work with the -alias switch</heading> <heading>Why don't most games work with the -alias switch</heading>