lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Aug 2015 21:19:32 +0800
From:	lucien xin <lucien.xin@...il.com>
To:	Vlad Yasevich <vyasevic@...hat.com>
Cc:	Marcelo Ricardo Leitner <mleitner@...hat.com>,
	network dev <netdev@...r.kernel.org>,
	Thomas Graf <tgraf@...radead.org>, davem <davem@...emloft.net>
Subject: Re: [PATCH net v2] sctp: start t5 timer only when peer.rwnd is 0 and
 local.state is SHUTDOWN_PENDING

>
> No, these are 2 distinct instances.  In one instance, the peer is reachable and
> is able to communication 0 rwnd state to us.  Thus we are being nice and granting
> the peer more time to exit the 0 window state.
>
> In the other state, the peer is unreachable and we just happen to hit the 0-window
> condition based on some estimations of the peer window.  In this case, we should
> be subject to the Max.RTX and terminate the association sooner.
>
> -vlad
>
okay, I got you,

we can see that local update their peer.rwnd in sctp_packet_append_data() and
sctp_retransmit_mark(), it do that according to a_rwnd and outstanding, so the
root reason is that it's hard to know that peer really closed it's window, maybe
just so many outstanding lead to that.

what we can do is to trust peer.rwnd is the real window in peer.
from another angle,  even though it's not real, at least we can reduce the
* the other state* you mentioned by doing this. especially, if there is only one
small packet keep retransmitting in SHUTDOWN_PENDING state, the
peer.rwnd is more believable to be the real peer window.

I saw bsd code didnot care about Max.Retrans in SHUTDOWN_PENDING,
instead it just start T5 timer. but now that we choose Max.Retrans + T5, it's
better to process more unreachable by using Max.Retrans. I also hope we can
do it better there as Marcelo said, but by now I cannot see it. :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ