Problem with 'resource temporarily unavailable'

[Edward King]

I haven't had time to play with this much -- we are loading the line, 
using rsync to transfer about 5 gig over a 384K dsl.  

I throttled the rsync back to 10k, and that didn't solve the problem but 
I think it's because other users on the network were causing congestion. 
 Over night there are no problems.

I'll increase the bandwidth to the point of failures and change the 
sleep to give it more time -- see if that allows some buffers to free up.

I am using the TCPonly -- and that's because we're behind a nat'ing 
firewall.  I've also gotten this error (now that I'm looking for it) 
whenever I push large amounts of data -- usually with dsl.

I'll keep you posted on what I find -- hopefully increasing the timeout 
will help.

Guus Sliepen wrote:

>On Wed, Jan 15, 2003 at 01:10:24PM -0600, Edward King wrote:
>
>  
>
>>We've got problems running tinc over DSL lines using low cost 
>>routers/modems (at leat I think it's a hardware problem.)
>>
>>We get error messages such as the following:
>>
>>Jan 15 11:36:05 stv100 tinc.stv100[2784]: Sending meta data to vpn 
>>(162.37.22.162 port 2007) failed: Resource temporarily unavailable
>>    
>>
>
>That usually indicates that no more network buffers are available,
>either because the machine is really low on memory or if more data is
>being sent out by tinc than the network can handle.
>
>tinc normally shouldn't send very much meta data (only a ping once a
>minute and some updates if a connection to another tinc daemon is made
>or broken) unless you're using the TCPonly option. Is it really
>necessary for you to use it? What kind of traffic are you sending over
>the VPN?
>
>  
>
>>I've added a delay to meta.c so if it errors out, retry in 1 second 
>>(using usleep(1000)).  I also made an it log every time it was going to 
>>retry and if it fails, log the failure.  the code looks like this:
>>    
>>
>
>usleep(1000) sleeps for 1 millisecond.
>
>  
>
>>we also changed the mtu on both sides to 1000 -- hoping to possibly 
>>remove problems there.
>>    
>>
>
>That probably doesn't matter much.
>
>  
>
>>We now get lots of 'will retry in 1000ms' messages, and very few 
>>'failed' messages.  
>>    
>>
>
>That's interesting.
>
>  
>
>>There are more messages on the sending side of 'Metadata socket error 
>>for vpn' Connection reset by peer' and the other side showing 'Bogus 
>>data received'
>>    
>>
>
>You really shouldn't see that unless errors were introduced in the TCP
>stream... Do those errors also occur less frequently with the usleep()
>than without?
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://brouwer.uvt.nl/pipermail/tinc/attachments/20030117/59090535/attachment.htm