Re: PopTop does not log why I can't connect when ip-pool is exhausted.

James,

Yes it does add complexity, and I've tested poptop 1.3.4 with this patch and
it passed my unit tests. Yet, I am limited to the hardware that I am working
on an XScale CPU on a IXP425 platform. 

The only impact I've seen this have, is that Windows would normally try to
connect for approx. 60s before it is giving up. Once it gives up, it
displays "Error 678: blah ..." stating that the server could not be
connected.

In the case you do pick up that connection, and terminate the link due to
high load / user count, it will display a different error message (I have to
go back and check, but I think it was 629 --
http://msdn2.microsoft.com/en-us/library/bb530704.aspx). 

But again, a sysadmin will have the ability to go and check the logs emitted
by the server. I think that would be expected in this case.

Best Regards,
- Eivind

James Cameron-2 wrote:
> 
> On Thu, Jul 19, 2007 at 09:46:08AM -0700, Eivind wrote:
>> You sit there and watch the logs pass by for 5 min and then you try to
>> connect with a third client. No response which is expected at this time
>> since you have exhausted the pool of ip-addresses. However, for debugging
>> purposes I'd still think that displaying the message would be
>> appropriate. 
> 
> I've reviewed this section of the code.  It is lines 243 to 254 of
> pptpmanager.c.
> 
> The logic of the program is that it is normally woken up to process an
> incoming connection.  But once the available connection slots are filled
> it will not ask the operating system to wake it until it has a child
> process terminate.
> 
> As a result, the listening queue on the socket becomes the pending
> connection queue, and file descriptors are not consumed.
> 
> This could be changed.  Do you have a proposed implementation?
> 
>> After studied the code for a bit, it seems like the fd that pptpd listens
>> for incoming connections is never added to the file descriptor set in
>> pptpmanager.c and hence why the select() never wakes up to tell us about
>> it.
> 
> What should happen is that the SIGCHLD from an exiting child will cause
> select(2) to return, and when the event loop restarts slot_find_empty()
> will return the empty slot, and so the file descriptor set will be set
> up with the listening socket.
> 
> Perhaps what is happening is that the pptpctrl processes are not exiting
> fast enough?
> 
>> In addition, the listener socket is configured to take at most 3 client
>> connections in its backlog.
> 
> While that is true, various operating systems provide a greater backlog
> than the three requested.  If the backlog is filled, an operating system
> would normally simply not reply to the SYN packet of the new connection.
> 
>> I would be very cautious about changing this select() loop code since it
>> obviously worked for years. Simply allowing a client to connect unlimited
>> number of times but close the socket if a slot cannot be found won't do
>> it
>> as pptpd *could* go into an infinite spin consuming lots of CPU resources
>> (*I think*). One can get around this by not adding the listen_fd to the
>> set
>> in the period where it is being blocked and then add a timeout of 10-15
>> seconds so no clients can connect; call this a hold-off period. Post this
>> hold-off period, the listener_fd is added back into the set allowing
>> clients
>> to reconnect again. This hold-off period can be interrupted in case some
>> other client logs off.
> 
> Patch reviewed.  This adds quite a bit of complexity.  Has it worked?
> 
> -- 
> James Cameron                         http://quozl.netrek.org/
> HP Open Source, Volunteer             http://opensource.hp.com/
> PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Poptop-server mailing list
> Poptop-server <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/poptop-server
> 
> 

--

-- 
View this message in context: http://www.nabble.com/PopTop-does-not-log-why-I-can%27t-connect-when-ip-pool-is-exhausted.-tf4112307.html#a12077642
Sent from the poptop-server mailing list archive at Nabble.com.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/