* Chris Smith [2014-03-17 23:41]:
> I think the source of this reported problem has been found, and
> happily fixed (the preliminary results are promising).
>
> Basically I needed to find some way to get the backups to complete
> reliably so I started a 20 count ping job a minute before the rsync
* Stuart Henderson [2014-01-27 13:18]:
> On 2014/01/26 14:53, Chris Smith wrote:
> > On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson
> > wrote:
> > > This could be an MTU or RWIN-related issue.
> >
> > Could my issue have anything to with the "miscounting bug for inbound
> > with pf on" menti
I think the source of this reported problem has been found, and
happily fixed (the preliminary results are promising).
Basically I needed to find some way to get the backups to complete
reliably so I started a 20 count ping job a minute before the rsync
job (actually an rsnapshot job which connect
On 2014/01/26 14:53, Chris Smith wrote:
> On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson
> wrote:
> > This could be an MTU or RWIN-related issue.
>
> Could my issue have anything to with the "miscounting bug for inbound
> with pf on" mentioned in the following commit?
> ==
On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson wrote:
> This could be an MTU or RWIN-related issue.
Could my issue have anything to with the "miscounting bug for inbound
with pf on" mentioned in the following commit?
CVSROOT:/cvs
Module name:
On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson wrote:
> Posting the firewall ruleset may possibly help people diagnose this in more
> detail.
Here's some pertinent pf.conf info:
===
set skip on { lo enc0 }
set block-policy drop
set reassemble yes no-df
set limi
On Wed, Jan 22, 2014 at 12:56 PM, Charles RAPENNE wrote:
> Do you rsync directly to an ip address or are you using avec domain name ?
Not DNS - directly to IP address.
Thanks,
Chris
er 2014 16:23À: Stuart HendersonCc:
OpenBSD-MiscObjet: Re: unreliable connections
On Mon, Jan 20, 2014 at 11:31 AM, Chris Smith
wrote:
> have moved the "block all" to the beginning of the ruleset to see if
> it will make any difference
Unfortunately no difference. The attempt to
On Mon, Jan 20, 2014 at 11:31 AM, Chris Smith wrote:
> have moved the "block all" to the beginning of the ruleset to see if
> it will make any difference
Unfortunately no difference. The attempt to rsync the first directory
failed last night, second one worked fine.
Any other ideas?
Thanks,
Ch
On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson wrote:
> This could be an MTU or RWIN-related issue. One common problem is if the
> firewall state is created from an already-established connection rather
> than a SYN packet, in this case the firewall can't keep track of the
> RWIN value which is
On 2014-01-16, Chris Smith wrote:
> This issue is still with me. Sporadically the connection will fail,
> and a connection attempt immediately after the failure will (so far)
> always work. Again the problem is only with this one remote firewall,
> all of the others are fine. the hardware is virtu
This issue is still with me. Sporadically the connection will fail,
and a connection attempt immediately after the failure will (so far)
always work. Again the problem is only with this one remote firewall,
all of the others are fine. the hardware is virtually identical,
similar versions of the Sup
I'm having a problem connecting with (and through) one OpenBSD box.
Both ends are running OpenBSD -current (-current as of last weekend)
and I've had the issue through a couple of months of various builds of
-current.
The problem occurs whether I'm connecting directly to the remote
OpenBSD box (fi
13 matches
Mail list logo
