Fred Wright wrote:
> On Mon, 7 Jul 2003, Manuel Kasper wrote:
>> On Sun, 6 Jul 2003, Fred Wright wrote:
>> 
>>> Only the GRE traffic is a problem, since there's no conflict with
>>> the control connection (as long as you don't need simultaneous
>>> client and server operation with respect to a single remote
>>> system).  So the PPTP code should be able to use the local IP
>>> address of the already-established control connection socket to
>>> bind() the (presumably raw) GRE socket.  It could even bind to the
>>> remote IP by using connect(), which also improves efficiency.
>> 
>> Interestingly, the reason for the "Address already in use" message
>> is not GRE, but the TCP port 1723 server socket. I sent Michiel a
>> slightly 
> 
> That's bizarre, unless the PPTP client is actually attempting to
> implement the shared client/server control connection, perhaps in a
> non-useful way.  Otherwise, there's no reason why the client would
> use *local* port 1723 at all.
> 
> Or are multiple server-side instances getting started?
> 
>> modified version of m0n0wall where the PPTP server uses "set pptp
>> self" (to 127.0.0.1) like the PPTP client does (which uses the
>> pseudo WAN IP 
> 
> What's it trying to do with loopback?  A connection bound to that IP
> couldn't leave the box.
> 
>> address assigned on the WAN->PPTP setup page). Still - the same
>> message... Looking at MPD's source code, it's clear that the message
>> originates from the bind() on the TCP server socket. I don't quite
>> understand why two different processes cannot bind to the same port
>> but on different IP addresses... I thought that was possible. MPD
>> even uses setsockopt(... 
> 
> It's possible if you use SO_REUSEADDR.
> 
>> SO_REUSEADDR ...) before the bind() - don't know what effect that
>> has, though.
> 
> It definitely needs that if it's using a fixed port locally.  Without
> SO_REUSEADDR, it's not even possible to bind a listener to a port
> when a *connection* exists involving that same local port, let alone
> another listener.  Part of the problem is that there's no way to
> atomically bind a socket to both local and remote addresses, since
> two separate calls are involved.
> 
>> Some more debugging may be in order, I guess. Maybe we have to check
>> if MPD really supplies the IP address given in "set pptp self" to
>> bind(). 
> 
> A good start would be to look with netstat while the client side is
> connected.
> 
> Fred Wright
> 
> 
Status.cgi will provide this information right?

M.