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,
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
> 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