Le 01/10/15 11:58, Lauri Tirkkonen a écrit :
> On Thu, Oct 01 2015 11:50:03 +0200, Richard PALO wrote:
In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better in
this case (or would OI not honour that setting correctly)?
>>>
>>> It wouldn't work. From what I can tell,
Le 01/10/15 14:23, Lauri Tirkkonen a écrit :
> On Thu, Oct 01 2015 13:49:03 +0200, Richard PALO wrote:
>> Le 01/10/15 11:58, Lauri Tirkkonen a écrit :
>>> On Thu, Oct 01 2015 11:50:03 +0200, Richard PALO wrote:
>> In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better
>>
On Thu, Oct 01 2015 13:49:03 +0200, Richard PALO wrote:
> Le 01/10/15 11:58, Lauri Tirkkonen a écrit :
> > On Thu, Oct 01 2015 11:50:03 +0200, Richard PALO wrote:
> In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better
> in
> this case (or would OI not honour that
On Thu, Oct 01 2015 14:29:32 +0200, Richard PALO wrote:
> >> Actually I still notice some problems.. This morning in the direction OI
> >> => omnios
> >> things seemed okay.
> >> Now, omnios => OI I just now experienced the hang again, and it is
> >> repeatable.
> >>
> >> Could it be that your
Le 30/09/15 10:02, Lauri Tirkkonen a écrit :
On Wed, Sep 30 2015 09:56:47 +0200, Richard PALO wrote:
To be clear, it's not implementing RFC 1323 (and not even *not*
implementing 7323) that causes the issue. 1323 actually didn't specify
what to do with non-timestamped segments on a
On Thu, Oct 01 2015 11:50:03 +0200, Richard PALO wrote:
> >>In that case, wouldn't setting tcp_tstamp_always on OI to '1' be better in
> >>this case (or would OI not honour that setting correctly)?
> >
> >It wouldn't work. From what I can tell, those ndd settings only affect
> >the SYN segments
On Wed, Sep 30 2015 09:56:47 +0200, Richard PALO wrote:
> >To be clear, it's not implementing RFC 1323 (and not even *not*
> >implementing 7323) that causes the issue. 1323 actually didn't specify
> >what to do with non-timestamped segments on a timestamp-negotiated
> >connection, and illumos
Le 29/09/15 12:35, Lauri Tirkkonen a écrit :
On Tue, Sep 29 2015 12:19:09 +0200, Richard PALO wrote:
Since I'm not having any issues with netbsd (6.1), which seemingly is still
at rfc1323
richard@omnis:/home/richard$ ssh netbsd.org /sbin/sysctl net.inet.tcp.rfc1323
net.inet.tcp.rfc1323 = 1
On Tue, Sep 29 2015 12:19:09 +0200, Richard PALO wrote:
> Since I'm not having any issues with netbsd (6.1), which seemingly is still
> at rfc1323
> >richard@omnis:/home/richard$ ssh netbsd.org /sbin/sysctl net.inet.tcp.rfc1323
> >net.inet.tcp.rfc1323 = 1
>
> I'd like to do some additional tests
Le 28/09/15 17:40, Lauri Tirkkonen a écrit :
It just occurred to me that if timestamp options don't get negotiated at
all on the connection, both peers should be fine with this injection and
continue to function. So as a workaround you could try disabling
timestamps on the oi_151a9 box. I see
On Mon, Sep 28 2015 16:20:03 +0200, Richard PALO wrote:
> Le 28/09/15 15:46, Lauri Tirkkonen a écrit :
> > On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote:
> >>
> >>> On Sep 28, 2015, at 8:15 AM, Dan McDonald wrote:
> >>>
> >>> If 5850 is indeed the problem, you need to
Le 28/09/15 15:46, Lauri Tirkkonen a écrit :
> On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote:
>>
>>> On Sep 28, 2015, at 8:15 AM, Dan McDonald wrote:
>>>
>>> If 5850 is indeed the problem, you need to report this to the
>>> illumos developers list, including a
On Mon, Sep 28 2015 16:20:03 +0200, Richard PALO wrote:
> Le 28/09/15 15:46, Lauri Tirkkonen a écrit :
> > On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote:
> >>
> >>> On Sep 28, 2015, at 8:15 AM, Dan McDonald wrote:
> >>>
> >>> If 5850 is indeed the problem, you need to
On Thu, Sep 10 2015 11:28:12 +0200, Richard PALO wrote:
> Le 08/09/15 14:12, Dan McDonald a écrit :
> >
> >>On Sep 8, 2015, at 12:32 AM, Richard PALO
> >> wrote:
> >>
> >>before the traffic seemingly when things go sour... I notice a Window
>
If 5850 is indeed the problem, you need to report this to the illumos
developers list, including a deterministic way of reproducing it.
Funny though, the fix was brought forth because of specific middlebox behavior.
It is POSSIBLE your middlebox is behaving differently than the bug-filer's
> On Sep 28, 2015, at 8:15 AM, Dan McDonald wrote:
>
> If 5850 is indeed the problem, you need to report this to the illumos
> developers list, including a deterministic way of reproducing it.
I see you filed bug 6264, which is a good first step. Please make sure you
Le 28/09/15 14:21, Dan McDonald a écrit :
>
>> On Sep 28, 2015, at 8:15 AM, Dan McDonald wrote:
>>
>> If 5850 is indeed the problem, you need to report this to the illumos
>> developers list, including a deterministic way of reproducing it.
>
> I see you filed bug 6264,
On Mon, Sep 28 2015 08:21:46 -0400, Dan McDonald wrote:
>
> > On Sep 28, 2015, at 8:15 AM, Dan McDonald wrote:
> >
> > If 5850 is indeed the problem, you need to report this to the
> > illumos developers list, including a deterministic way of
> > reproducing it.
>
> I see
Le 26/09/15 17:33, Richard PALO a écrit :
> Le 08/09/15 06:32, Richard PALO a écrit :
>> Thought I would try snoop with port 22.
>>
>> From omnios, in one window I issued:
>>> pfexec snoop -rv -d e1000g0 port 22 |& tee snoop.out
>>
>> From another I connected to the OI machine and did nothing
Le 08/09/15 06:32, Richard PALO a écrit :
> Thought I would try snoop with port 22.
>
> From omnios, in one window I issued:
>> pfexec snoop -rv -d e1000g0 port 22 |& tee snoop.out
>
> From another I connected to the OI machine and did nothing further (as it
> hangs in that direction too):
>>
Le 08/09/15 14:12, Dan McDonald a écrit :
On Sep 8, 2015, at 12:32 AM, Richard PALO wrote:
before the traffic seemingly when things go sour... I notice a Window changed
to 1024??
Which side is advertising the window change again? And which side is running
-gate from
Le 08/09/15 14:12, Dan McDonald a écrit :
On Sep 8, 2015, at 12:32 AM, Richard PALO
wrote:
before the traffic seemingly when things go sour... I notice a Window changed
to 1024??
Which side is advertising the window change again? And
Le 24/08/15 19:14, Eric Sproul a écrit :
On Mon, Aug 24, 2015 at 12:04 PM, Richard PALO
richard-s783fymb3ccdnm+yrof...@public.gmane.org wrote:
notice inbound invalids and nomatches both ways... are they a concern?
I have no idea. I might try adding an unconditional pass rule for the
Le 24/08/15 18:05, Eric Sproul a écrit :
What you describe sounds network-related, perhaps just a coincidence
that it happened recently. However, it also sounds like the
behavior changes depending on whether you use an older BE or a newer
one, so that makes it seem *less* likely that it is an
On Mon, Aug 24, 2015 at 10:35 AM, Richard PALO rich...@netbsd.org wrote:
The machines do not belong to the same subnet. They are physically remote
and the omnios machine is behind a router with port forwarding.
The OI machine *is* multihomed, though.
What strikes me most is that previous
I just tried this reproduction on my OmniOS box:
1.) ssh to OI 151a9.
2.) ssh from 151a9 to bloody
3.) cat $illumos-gate/usr/src/uts/common/inet/ip/ip.c (a large file)
No breakage.
4.) git log -p ip.c -- it uses less -M by default, so that stopped waiting
for input.
5.) git log -p ip.c |
26 matches
Mail list logo