On Tue, Jun 24, 2014 at 10:39:46PM +1000, Darren Reed wrote:
So the problem is this:
* sshd tries to write to the socket, gets ENETUNREACH
and then exits leading to the FIN packets being transmitted as the socket
is closed down in the normal course of things but by the time it is doing
On Tue, Jun 24, 2014 at 11:39:47PM +1000, Darren Reed wrote:
Oh, I forgot, there are internal code paths in ipfilter/npf that can
return ENETUNREACH.
If you are using NetBSD 6 with ipfilter, comparing the output of this:
ipfstat | grep 'block reason'
from before and after might be
On Tue, Jun 24, 2014 at 11:01:01PM +1000, Darren Reed wrote:
From that capture file, there is only *one* packet with the FIN bit set
(line 20076):
Yes.
09:24:10.646480 IP (tos 0x0, ttl 64, id 6680, offset 0, flags [DF],
proto TCP (6), length 1084)
85.X.X.X.22 77.X.X.X.59412: Flags
On Mon, Jun 23, 2014 at 10:16:21PM +0200, Manuel Bouyer wrote:
So it could actually have closed the connection after that.
Did your tcpdump sequences also capture ICMP traffics ?
Did an ICMP network unreacheable packet show up ?
I just created a new capture, this time with icmp:
On Mon, Jun 23, 2014 at 08:48:04PM +0200, Joerg Sonnenberger wrote:
On Mon, Jun 23, 2014 at 07:19:41PM +0200, Petar Bogdanovic wrote:
Good question, I forgot to add that to my original message. Until now,
only scheduled ssh-tunnels were affected. interactive ssh-sessions seem
fine, so
On 23/06/2014 8:24 PM, Petar Bogdanovic wrote:
During the past few weeks the ssh-tunnels to a remote machine started
failing randomly. In a previous mail to tech-net I prematurely blamed
ipfilter because disabling it yielded some immediate success.
Unfortunately, subsequent testing showed
On 24/06/2014 10:39 PM, Darren Reed wrote:
On 23/06/2014 8:24 PM, Petar Bogdanovic wrote:
... * sshd bails on a failed write() with ENETUNREACH
So the problem is this:
* sshd tries to write to the socket, gets ENETUNREACH
and then exits leading to the FIN packets being transmitted as the
On Tue, Jun 24, 2014 at 10:44:12AM +0200, Daniel Hartmeier wrote:
Have you tried with all packet filters disabled, just to make sure?
When this started, I actually did disable ipfilter. But back then the
failures were declining so when I finally decided to go filterless, the
problem was no
On Mon, Jun 23, 2014 at 12:24:08PM +0200, Petar Bogdanovic wrote:
Unfortunately, subsequent testing showed that having npf enabled instead
eventually lead to the same issues.
Clarification: both ipf and npf were/are configured and enabled at the
server and not somewhere in between (or at the
On 06/23/2014 09:25 AM, Petar Bogdanovic wrote:
But the thing is.. the server apparently
sends a FIN.. hence the server closes the
connection, nothing in between. And it
does so out of the blue without any
messages or errors.
It's still hard to say that there is nothing interfering with the
Petar Bogdanovic pe...@smokva.net wrote:
During the past few weeks the ssh-tunnels to a remote machine started
failing randomly. In a previous mail to tech-net I prematurely blamed
ipfilter because disabling it yielded some immediate success.
Unfortunately, subsequent testing showed that
On Mon, Jun 23, 2014 at 09:50:59AM -0700, Brandon Vincent wrote:
On 06/23/2014 09:25 AM, Petar Bogdanovic wrote:
But the thing is.. the server apparently
sends a FIN.. hence the server closes the
connection, nothing in between. And it
does so out of the blue without any
messages or
On Mon, Jun 23, 2014 at 05:53:10PM +0100, Mindaugas Rasiukevicius wrote:
Are you using 6.x or -current? If latter, is it the latest -current?
The setup is conservative, follows netbsd-6-0.
On Mon, Jun 23, 2014 at 12:24:08PM +0200, Petar Bogdanovic wrote:
During the past few weeks the ssh-tunnels to a remote machine started
failing randomly. In a previous mail to tech-net I prematurely blamed
ipfilter because disabling it yielded some immediate success.
Unfortunately,
14 matches
Mail list logo
