From owner-freebsd-net Wed Mar 27 11:11:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by hub.freebsd.org (Postfix) with SMTP id B726437B416 for ; Wed, 27 Mar 2002 11:11:20 -0800 (PST) Received: (qmail 74814 invoked by uid 1013); 27 Mar 2002 19:11:19 -0000 Date: Wed, 27 Mar 2002 20:11:19 +0100 From: Markus Stumpf To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: freebsd-net@FreeBSD.ORG Subject: Re: problems with udp46 sockets Message-ID: <20020327201119.E68348@Space.Net> References: <20020326231734.H58573@Space.Net> <20020327.162320.922733592.keiichi@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020327.162320.922733592.keiichi@iij.ad.jp>; from keiichi@iij.ad.jp on Wed, Mar 27, 2002 at 04:23:20PM +0900 Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Mar 27, 2002 at 04:23:20PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > This is a cached route problem. struct inpcb has a route entry for > cached route. Since inpcb is shared by both IPv4 and IPv6, the cached > route entry is also shared by them. 4.5-STABLE doesn't check the > protocol family of the cached route when using it. Therefore, once a > IPv4 route is cached, ip6_output mistakingly use it as a cached route > for IPv6 destination. > > Please try attached patches. Thanks a lot! I have applied the patches and it works only partially. I have the server at de0: flags=8943 mtu 1500 inet6 fe80::280:c8ff:fe45:b392%de0 prefixlen 64 scopeid 0x1 inet 195.30.1.139 netmask 0xffffff00 broadcast 195.30.1.255 inet6 2001:608:0:1:280:c8ff:fe45:b392 prefixlen 64 autoconf ether 00:80:c8:45:b3:92 the IPv4 only client is at de0: flags=8843 mtu 1500 inet 195.30.1.54 netmask 0xffffff00 broadcast 195.30.1.255 ether 00:80:c8:4c:33:36 the IPv6 client is at de0: flags=8843 mtu 1500 inet 195.30.0.29 netmask 0xffffff00 broadcast 195.30.0.255 inet6 fe80::280:c8ff:fe56:bf25%de0 prefixlen 64 scopeid 0x1 inet6 2001:608::1000:1 prefixlen 64 inet6 2001:608::280:c8ff:fe56:bf25 prefixlen 64 ether 00:80:c8:56:bf:25 queries from the IPv6 client both to 2001:608:0:1:280:c8ff:fe45:b392 or 195.30.1.139 work fine, always. As long as I only do queries via IPv4 it works for both clients. As the IPv4 client and the server are on the same subnet/ethernet they can talk directly. What happens is that the server has two ARP entries as soon as a query via IPv4 comes in: lagrange.Space.Net (195.30.1.54) at 0:80:c8:4c:33:36 on de0 [ethernet] lagrange.Space.Net (195.30.1.54) at (incomplete) on de0 [ethernet] As soon as I do the first query via IPv6 I can do further queries via IPv6 from that host but queries via IPv4 from any host on the same subnet/ethernet don't work any longer. truss shows the sendto() without any errors. recvfrom(0x3,0x80556c0,0x400,0x0,0xbfbffbc0,0xbfbffbbc) = 31 (0x1f) [ ... ] sendto(0x3,0x80f34c0,0x2f,0x0,0xbfbffba0,0x1c) = 47 (0x2f) tcpdump shows that at the moment the server does the sendto() the server host sends ARP requests and gets answers but doesn't send any packets: 19:56:26.381491 195.30.1.54.2494 > 195.30.1.139.53: 6+ A? www.space.net. (31) 19:56:26.382267 arp who-has 195.30.1.54 tell 195.30.1.139 19:56:26.382366 arp reply 195.30.1.54 is-at 0:80:c8:4c:33:36 arp -a still shows the above two entries (one incomplete). Same happens if I use other hosts e.g.: moebius2.Space.Net (195.30.1.100) at 0:d0:b7:a9:2e:5b on de0 [ethernet] moebius2.Space.Net (195.30.1.100) at (incomplete) on de0 [ethernet] and no packets get out: 20:02:56.283806 195.30.1.100.3227 > 195.30.1.139.53: 6+ A? www.space.net. (31) 20:02:56.284575 arp who-has 195.30.1.100 tell 195.30.1.139 20:02:56.284753 arp reply 195.30.1.100 is-at 0:d0:b7:a9:2e:5b I have also tried # arp -a -d but that doesn't change anything. ping and ssh still work for all clients to the server. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message