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 w
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
>> i
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
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, thos
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 (ie
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 timestamp-nego
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 pre-5
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
I'
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 i
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 the
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 report this to the
>
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 report this to the
>
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 deterministic way of
>>> rep
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 you filed bug 6264, wh
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, which is a good first st
> 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
summarize the how-to-rep
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
mid
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
> >>changed to 1024??
> >
> >Which side is advertising t
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 furth
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):
>> ss
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 2ed96329a073f74bd33f
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 2ed96329a073f74bd33f7
> 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 2ed96329a073f74bd33f766ab982be14f3205bc9 ?
This thread has
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):
> ssh xx.xx.xxx.xx
In the attached snoop.output, I edite
Le 24/08/15 19:14, Eric Sproul a écrit :
> On Mon, Aug 24, 2015 at 12:04 PM, Richard PALO
> 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
> OmniOS system to ensure it's not matching any
On Mon, Aug 24, 2015 at 12:04 PM, Richard PALO 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
OmniOS system to ensure it's not matching any other ipfilter rules, or
if possible, disable ipfilte
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
On Mon, Aug 24, 2015 at 10:35 AM, Richard PALO 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 versions of omnios
Le 24/08/15 16:26, Eric Sproul a écrit :
> On Sun, Aug 23, 2015 at 9:19 PM, Dan McDonald wrote:
>> I'm not seeing it. Do you maybe have PathMTU issues, or are these
>> same-subnet machines?
>
> This sounds a lot like a split-path routing issue, so knowing whether
> these machines are on the sam
On Sun, Aug 23, 2015 at 9:19 PM, Dan McDonald wrote:
> I'm not seeing it. Do you maybe have PathMTU issues, or are these
> same-subnet machines?
This sounds a lot like a split-path routing issue, so knowing whether
these machines are on the same subnet would be key.
I've had this happen in the
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
Le 21/08/15 23:12, Dan McDonald a écrit :
>
>> On Aug 21, 2015, at 4:37 PM, Richard PALO
>> wrote:
>>
>> There seems to be a recent regression somewhere as when I ssh in from
>> an OI machine to my bloody dev machine running recent vanilla bits, my
>> session hangs relatively soon.
>> I'm using
Le 21/08/15 23:12, Dan McDonald a écrit :
>
>> On Aug 21, 2015, at 4:37 PM, Richard PALO wrote:
>>
>> There seems to be a recent regression somewhere as when I ssh in from
>> an OI machine to my bloody dev machine running recent vanilla bits, my
>> session hangs relatively soon.
>> I'm using bas
> On Aug 21, 2015, at 4:37 PM, Richard PALO wrote:
>
> There seems to be a recent regression somewhere as when I ssh in from
> an OI machine to my bloody dev machine running recent vanilla bits, my
> session hangs relatively soon.
> I'm using bash as my login shell
I used tcsh as mine, and my
There seems to be a recent regression somewhere as when I ssh in from
an OI machine to my bloody dev machine running recent vanilla bits, my session
hangs relatively soon.
I'm using bash as my login shell
> richard@omnis:/home/richard$ bash --version
> bash --version
> GNU bash, version 4.3.33(1)-
35 matches
Mail list logo
