NetBSD Problem Report #56348

From kardel@Kardel.name  Wed Aug  4 17:44:02 2021
Return-Path: <kardel@Kardel.name>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C71A71A921F
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  4 Aug 2021 17:44:02 +0000 (UTC)
Message-Id: <20210804160804.B702B44B33@Andromeda.Kardel.name>
Date: Wed,  4 Aug 2021 18:08:04 +0200 (CEST)
From: kardel@netbsd.org
Reply-To: kardel@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: MTU discovery fails with IPv6 sockets bound to IPv4 mapped address
X-Send-Pr-Version: 3.95

>Number:         56348
>Category:       kern
>Synopsis:       MTU discovery fails with IPv6 sockets bound to IPv4 mapped address
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 04 17:45:00 +0000 2021
>Closed-Date:    Wed Aug 11 19:31:13 +0000 2021
>Last-Modified:  Wed Aug 11 19:31:13 +0000 2021
>Originator:     Frank Kardel
>Release:        NetBSD 9.99.86
>Organization:

>Environment:


System: NetBSD kebne-new 9.99.86 NetBSD 9.99.86 (GENERIC) #3: Wed Aug 4 15:43:10 CEST 2021 kardel@pip:/src/NetBSD/cur/src/obj.amd64/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	Setup:
		Server socket bound to ::ffff:A.B.C.D
		Client reaches server via IPSEC VPN -> MTU 1280
	Effects:
		On first access the server delivers all data to client - ok.
		On subsequent accesses only partial data is delivered and
		the writev(2) in the server experiences error 40 (EMSGSIZE).
		Bindung a true IPv4 socket works and does not show
		MTU discovery problems.
	State observations:
		At the first access no host route for the client
		is known at the server node. After the first
		access the ICMP/NOTREACH/NEEDFRAG-1280 packets install
		a dynamic host route with the correct MTU of 1280.
		Deleting the IPv4 host route result in a successful
		transfer again for IPv6 sockets bound to mapped IPv4
		addresses.
	Analysis:
		Dtracing shows that on the error case ip_output()
		returns EMSGSIZE for the first ip_output() call.
		This is caused by mtudisc being active (IPv6 standard) and
		thus IP_DF is in effect and ip_output cannot fragment.
		Further dtracing shows that the TCP connection has
		a cached route in the failure case:
Internet6:
Destination                             Gateway                        Flags    Refs      Use    Mtu Interface
::ffff:0.0.0.0/96                       ::1                            UGRS        -        -  33624  lo0
		Thus TCP assumes an MTU of 33624 and due to IPv6 MTU
		discovery ip_output returns EMSGSIZE.

		The route entry is picked up during connection completion
		in ip_input from the syn-cache via
		in6_pcbconnect>in6_selectsrc>in6_selectif>in6_selectroute.

		in6_selectroute looks up the route for the IPv4 mapped
		destination address via the IPv6 routing table and gets
		there a match of the statically configured route from
		above. with that MTU(33624) TCP is suffciently confused
		and produces above effects.

>How-To-Repeat:
	see above.
	Server test program:
begin 644 tcpresponder.c.gz
M'XL("$D9"F$``W1C<')E<W!O;F1E<BYC`*U8>T_;2!#_._D4TUPI#@0"I5AW
M0$"(`S4J+1&OZZE%D6.OPZJ)'7G7X7%WW_UF9G<=.PDJ.EVKUKNSNS._>0^T
MU^JP!F\_BB`2V5M<\_8D$X$6T1Y<YP*.\R'`#FS]MK?C[^WZ\'[K_3:XJR?I
MY"F3PWL-WDG3'`V>X"P+DA_P*<@B,<);[?HO,@E'>23@0#VI=B[3S?O#.:+2
M@5Y"3<,?8HZ>""WQ7ULF57J038(VG<RQT9E,AE6:3+1^F@@U?S-:0*:CD1Q4
M:7DBD5REQ6&B1U62R#(BU$DQ&<(TE5$]5\%0>+1LUO^JU^()0M.QA^SP=@L:
M?+X'*PH.NKWI!PBB*!-*_8T;WVT.X6"29AH_2@S'(M&@Y+/`;2Q'XO![TFC!
M4.A)E@Z38"R\9G._7A./4GNG7[O7_;/C[OG-Y2D2_ZG747A]',C$PP4$V3!L
M07@?9+"&Z^FW.\:(1^/@L:]![O,&,E(H5W8W]>TBCEJ@(MP8#B*))O:$T-HE
M(B:P+5X@C3;(6CT7[T@)PHV$/%%RF(C(8AKD<2S02&N3_1J^U%D>XDO$PO\-
M]@N:3*<BA#7\S&@41V2_ODS8CDM/C(G])6=*IQEZ!A2#1BJ")-SX<<@1WK=?
MM^YP2W]E#!X9%`Y@MPEHQIIQ/3D##0_V3[TV%F,EM/>.Q+1@J\7.3&./]NRZ
M\@5__H9/5XPT"OS^1*>)=WS6[WXYO6X!>W'[K@7\>%/)I,]LH=.!;8,*PZH#
M6RBF5EQ!G9!6AE$YCH.Q'#WA#2N&%`(Q4@*6HO#G8?C$Q5\.9-M)LI<6H/C-
MN1OS:/P9'.**6?58B7O,L5AB!!.HG)-GG.-N(""`:3"2$6#6I=EL5Z1=P[JN
M)@F2SG0J/=;L/6E&X<[.V6Z!O[N[LXLTFRCTCDSCMB\"HSPIX&"<ZGL!6$@Q
M[-(8MC<WF:^%4>/+'4K*140[_Q>B<H%Y-3*;XP8<IH++:"0PN@\F1^((">E$
M))Z[T(*+_N7O%U_._W0`Z4X'-K8+A`N^#/!M!#IE3O"]L:*^-[``.I:%SX@9
M:>M1F7K'!:/Y:MY83IDC!!I[R2#78A8-MH(W6&6TAH$`*Z,(&R%>Y'H\TY`E
M;RK=I_N<NV0NM(17.8%U5RIA@S*D[;9L.B?S%Z;"2L1":-W<=\6'3P[AIGO1
M_WS\M7MQ^[*7L6-AO\>,F8G4:0KC('ER`L##'H#?II73*C.VEC#U&549!Z-1
M&GKSJC(L=ZD#7V[.SU_&E"?!``V.QF=F.(T8#YCW+M209SHM232%HMP&FCBC
M.,-P?:+[_T&XZ2E!E@5/C7)0>91[:+V(`\NUJ*KJ37C3F2.Q:,93#L)E43C#
M0E*61WBYXBU5B)\6(8D9K#11,%R)B.X6V5@F.*8D0V0M%\.T1M8FG<WL$HY2
M)5!C#N`)6L`H3KWQ&>9T16*,!94-M;5/K=YJGTZ_R;M-_/0'%'P=H'FA3+;5
M_QD..T5H'A6K/3,UH/CU#E1?$1F?;2RCR_5UZSY%!<C,EQZ6^2/HV1:"K'NN
MA5Y=G'SJ7UU?GAY_;D&WU[N\N+[H7Y_TBK:K?E:B9@X,>:H&?-WN]JSD4B0C
MLS=3W_`INJTM\_?8495'&W8&Z4%6ETF$`%K@S<TKL-:T`\7\-%&*%)K'TCAV
M_;_:5Y?)M2&+TPC)22>:93NC='NW/NUN_?ZM3T4<ZRRR=Q!(5*7BUAZ"+/%*
MYM%YEI3?TXN&B[U7J^POSD>5.CW"V5TD&.B0)C1GLZ*F@M9K=BKC(2;1Z<3$
MQ?$L+MQH1?B!#SDA"N&SV08O5XZ*Z<N\Q80I+(/K)E$+,R\4AB5A=59T)S()
M?:TFF,`N3ER1,CJSV79_UO7,73#-;Q:=JCR*F3'XX9X*LL=-&H(P%#8@EGE&
M*>JZR,,40R<_Q.C2=KP'JB,SRRNUJ90=[]ADQCEE,FE2^.9H=J>PNS</A6=\
MAM/<."RYZI5ORT]GOC0/YQVZ;[-E4FTW-NH+/:VAH9AC5^C'*&-L]F7%#GS"
MK+GJ-HX:I?1P$7Z2)HD(M<3XCK-TC"DU70DQU/=<E+LP?\&6&-2K'U8Q?E?]
MU=+M27GM"A$+5O>YCM*'A%O@U<>;:YSB"OVY[C]D4HLIGV,IMJ/*2VUQ25]<
MJ!6&H1NV/!Q0F&5UU+)MO]H>F=6CUWC(4JS%+_7$E[H@V[K,SAG]BL;D&3>$
MN&)&OPH/3,UR05LTW!^7?%[JK[5EJ<<I&6="T#Q#EWAMFC!M,\'%=(M_R&^;
3W^F<I\.W_+N8?P'"JV_R\Q$`````
`
end
	Use netcat as client. Send file with 16k size. via
	an IPSEC VPN. After the first successful transfer
	you should see an error on the sender side and
	only about 2k on the receiver side.

>Fix:
	Workaround 1: don't use an IPv6 socket bound with an IPv4 mapped address.
	Workaround 2: delete the ::ffff:0.0.0.0/96 ::1 route - what is the
                      rationale for that route anyway?
	Proposed fix: make in6_selectroute fetch an IPv4 route
                      entry for IPv4 mapped addresses.
begin 644 ipv6mtu.patch.gz
M'XL("-RU"F$``VEP=C9M='4N<&%T8V@`I5++;MLP$#Q;7S&GP`_)>E25'1LI
M'#0]&$@#(T&"W@1"HF+""FF0E)V@R+]W23EI@.96`N**N\/9X>ZN9<V?%Q"R
M*(VNIE5P\?\KN/U^AT:T?(&X.ABME(V)/#8O)I;<"OJ*^#UC>`@TMUKP@Y"/
MT&2,4!+I=#X+:M$TB#I$VAT_J(RBZ.]ID,UQV3TB2[($2;'XDBVR'%%":^!I
M)I/)!W3^!DZ1?EWD^2+)>G"P6B$JTBPL,'%FAM4JP,!8W546VG)I]0O&VN("
M-_?7UTL*=M*)_4U_;SBCJAVK:ST8U,8N@\D_@5)(%\J7GURB6.&"A0N^HB/3
MJYJ=A^>D:IZ$Z4D6QK@W'`P5J[:\AE:=Y1`-A`5_%L8:,%E#&!Q8*^H0O"6X
M>X%58&VK*F9YS\,@^1%*\BEPHXC%;IG%D<-L5=?6(/YJ1T[*1AJY,6C8DVA?
MH!KG[4E.,FINJ,/,4EE"*CJY*2OAS)9IUV#'XJ$X"KO%>G/(IU0DC/V&1FD\
MY'AB^SV1G=)QX\0<F;1.^UZ0F&[OF0YY_^[^LN$<F]MXQ[7$+[^\M#B(!MW4
M594:-R;KJKU\=TZ-GXU*[7DI:H(DKFM4R.'ZIBC7=^7EU=5M^9#_O-QL?EP-
MSTX$T3=_STD<C6@"J-&>QVV9,\,SSY^'.-T8.=[7O@\>_XFH=^_GJEZ#"3W)
G3Z"VOHQEJ]2NVZ?#L58A^I0ATI&;'/A7.'0_L*/@#Z_0YU?O`P``
`
end

>Release-Note:

>Audit-Trail:
From: "Frank Kardel" <kardel@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56348 CVS commit: src/sys/netinet6
Date: Tue, 10 Aug 2021 06:29:56 +0000

 Module Name:	src
 Committed By:	kardel
 Date:		Tue Aug 10 06:29:56 UTC 2021

 Modified Files:
 	src/sys/netinet6: in6_src.c

 Log Message:
 PR kern/56348
 MTU discovery fails with IPv6 sockets bound to IPv4 mapped address

 pick up the IPv4 route for IPv4 mapped IPv6 address to get the correct
 MTU and not any unrelated/inappropriate MTU from IPv6 routes. IPv4 mapped
 IPv6 addresses are always handled by the IPv4 stack and MTU discovery
 is solely handled with the IPv4 routing table.


 To generate a diff of this commit:
 cvs rdiff -u -r1.87 -r1.88 src/sys/netinet6/in6_src.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: PR/56348 CVS commit: src/sys/netinet6
Date: Wed, 11 Aug 2021 11:01:38 +0200

 Pullups requested:
 [pullup-8 #1690] pullup fix for PR kern/56348 MTU discovery fails with 
 IPv6 sockets bound to IPv4 mapped address
 [pullup-9 #1332] pullup fix for PR kern/56348 MTU discovery fails with 
 IPv6 sockets bound to IPv4 mapped address

State-Changed-From-To: open->needs-pullups
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Wed, 11 Aug 2021 09:12:35 +0000
State-Changed-Why:
change tested with -8 and -9
pullups requested


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56348 CVS commit: [netbsd-9] src/sys/netinet6
Date: Wed, 11 Aug 2021 17:22:17 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug 11 17:22:17 UTC 2021

 Modified Files:
 	src/sys/netinet6 [netbsd-9]: in6_src.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1332):

 	sys/netinet6/in6_src.c: revision 1.88

 PR kern/56348

 MTU discovery fails with IPv6 sockets bound to IPv4 mapped address
 pick up the IPv4 route for IPv4 mapped IPv6 address to get the correct
 MTU and not any unrelated/inappropriate MTU from IPv6 routes. IPv4 mapped
 IPv6 addresses are always handled by the IPv4 stack and MTU discovery
 is solely handled with the IPv4 routing table.


 To generate a diff of this commit:
 cvs rdiff -u -r1.85 -r1.85.6.1 src/sys/netinet6/in6_src.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56348 CVS commit: [netbsd-8] src/sys/netinet6
Date: Wed, 11 Aug 2021 17:24:43 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug 11 17:24:43 UTC 2021

 Modified Files:
 	src/sys/netinet6 [netbsd-8]: in6_src.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1690):

 	sys/netinet6/in6_src.c: revision 1.88

 PR kern/56348

 MTU discovery fails with IPv6 sockets bound to IPv4 mapped address
 pick up the IPv4 route for IPv4 mapped IPv6 address to get the correct
 MTU and not any unrelated/inappropriate MTU from IPv6 routes. IPv4 mapped
 IPv6 addresses are always handled by the IPv4 stack and MTU discovery
 is solely handled with the IPv4 routing table.


 To generate a diff of this commit:
 cvs rdiff -u -r1.79.6.2 -r1.79.6.3 src/sys/netinet6/in6_src.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: needs-pullups->closed
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Wed, 11 Aug 2021 19:31:13 +0000
State-Changed-Why:
pull-ups done. thanks!


>Unformatted:

Home	PR Database Search