Hi,
On 2016-06-16, at 23:09, Andrey Vagin wrote:
> I can't reproduce this issue, now I'm trying to understand why it works
> for me and doesn't work for you.
just to conclude this thread for the list:
Andrey and me debugged this off-list. The issue arose, because my code did a
bind() to 0.0.0
On Thu, Jun 16, 2016 at 07:51:22AM +, Eggert, Lars wrote:
> Hi,
>
> On 2016-06-14, at 23:21, Andrey Vagin wrote:
> > On my host, I see that dst is set in tcp_v4_connect() -> sk_setup_caps()
>
> sorry, are you saying that you don't see the issue with TCP_MSS_DEFAULT-sized
> segments after TC
Hi,
On 2016-06-14, at 23:21, Andrey Vagin wrote:
> On my host, I see that dst is set in tcp_v4_connect() -> sk_setup_caps()
sorry, are you saying that you don't see the issue with TCP_MSS_DEFAULT-sized
segments after TCP_REPAIR on your kernel? Or are you saying my quick attempt at
analyzing th
On Tue, Jun 14, 2016 at 07:37:12PM +, Eggert, Lars wrote:
> Hi,
>
> On 2016-06-14, at 19:15, Andrey Vagin wrote:
> > Recently we found that we have to restore more parameters for tcp
> > sockets.
> > https://patchwork.kernel.org/patch/9144995/
>
> thanks for the pointer.
>
> > As for your p
Hi,
On 2016-06-14, at 19:15, Andrey Vagin wrote:
> Recently we found that we have to restore more parameters for tcp
> sockets.
> https://patchwork.kernel.org/patch/9144995/
thanks for the pointer.
> As for your problem, criu saves and restores mss_clamp. Could you check
> that it works for you
Hi,
Recently we found that we have to restore more parameters for tcp
sockets.
https://patchwork.kernel.org/patch/9144995/
As for your problem, criu saves and restores mss_clamp. Could you check
that it works for your case?
on dump:
static int tcp_stream_get_options(int sk, struct tcp_in
On 2016-06-14, at 15:24, Eggert, Lars wrote:
> On 2016-06-14, at 15:10, Eric Dumazet wrote:
>> Also, is it a regression ? Was this working better with an older linux
>> version ?
>
> No idea, 4.6.0 is the only kernel I ran this on (is a new project). What
> would be a good older version to chec
On 2016-06-14, at 15:10, Eric Dumazet wrote:
>> What gives :
>> sysctl net/ipv4/ip_no_pmtu_disc net/ipv4/tcp_mtu_probing
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.tcp_mtu_probing = 0
> Also, is it a regression ? Was this working better with an older linux
> version ?
No idea, 4.6.0 is the only kern
On Tue, 2016-06-14 at 06:03 -0700, Eric Dumazet wrote:
> On Tue, 2016-06-14 at 11:40 +, Eggert, Lars wrote:
> > On 2016-06-14, at 13:28, Pavel Emelyanov wrote:
> > > Andrey (in Cc) has played with TCP_REPAIR recently, I guess he can know
> > > something.
> >
> > Thanks for CC'ing him. We loo
On Tue, 2016-06-14 at 11:40 +, Eggert, Lars wrote:
> On 2016-06-14, at 13:28, Pavel Emelyanov wrote:
> > Andrey (in Cc) has played with TCP_REPAIR recently, I guess he can know
> > something.
>
> Thanks for CC'ing him. We looked a little bit more into this:
>
> When TCP_REPAIR is on, tcp_co
On 06/10/2016 02:22 PM, Eggert, Lars wrote:
> Hi,
>
> I see an issue with TCP_REPAIR on kernel 4.6.0, where a migrated connection
> is only sending minimum-sized
> segments (~500 bytes), although the interfaces and path support
> Ethernet-sized MTUs. A connection that
> doesn't use TCP_REPAIR o
On 2016-06-14, at 13:28, Pavel Emelyanov wrote:
> Andrey (in Cc) has played with TCP_REPAIR recently, I guess he can know
> something.
Thanks for CC'ing him. We looked a little bit more into this:
When TCP_REPAIR is on, tcp_connect() directly calls tcp_finish_connect() before
returning, passin
12 matches
Mail list logo
