sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled (cc35c3d1) · Commits · 戴 / test

Currently, if PMTU discovery is disabled on a given transport, but the configured value is higher than the actual PMTU, it is likely that we will get some icmp Frag Needed. The issue is, if PMTU discovery is disabled, we won't update the information and will issue a retransmission immediately, which may very well trigger another ICMP, and another retransmission, leading to a loop. The fix is to simply not trigger immediate retransmissions if PMTU discovery is disabled on the given transport. Changes from v2: - updated stale comment, noticed by Xin Long Signed-off-by:

Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:

David S. Miller <davem@davemloft.net>

net/sctp/input.c

+12 −12

Original line number	Diff line number	Diff line
		@@ -399,20 +399,20 @@ void sctp_icmp_frag_needed(struct sock sk, struct sctp_association asoc,
		return;
		}

		if (t->param_flags & SPP_PMTUD_ENABLE) {
		if (!(t->param_flags & SPP_PMTUD_ENABLE))
		/* We can't allow retransmitting in such case, as the
		* retransmission would be sized just as before, and thus we
		* would get another icmp, and retransmit again.
		*/
		return;

		/* Update transports view of the MTU */
		sctp_transport_update_pmtu(t, pmtu);

		/* Update association pmtu. */
		sctp_assoc_sync_pmtu(asoc);
		}

		/* Retransmit with the new pmtu setting.
		* Normally, if PMTU discovery is disabled, an ICMP Fragmentation
		* Needed will never be sent, but if a message was sent before
		* PMTU discovery was disabled that was larger than the PMTU, it
		* would not be fragmented, so it must be re-transmitted fragmented.
		*/
		/* Retransmit with the new pmtu setting. */
		sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
		}

Admin message