ipv4-mapped ipv4 connect() for UDP broken in test10
Subsystems (3)
My IPv6 port for djbdns' dnscache does not work with -test10.
The symptom is that all queries time out.
Some digging reveals that djbdns does this (with scope_id 0):
socket(PF_INET6,...)
bind socket to ::
connect() socket to IP of peer (in this case, 210.81.13.179) send() dns query
at this point, the query is not sent over ppp0 as it should, but it is sent to lo. Not only that, but the queries are _received_ by the same djbdns (with servfail), although the destination IP is as said above 210.81.13.179 and none of my local IPs: 10.0.0.6, 127.0.0.1, or 217.88.123.45.
Any ideas? Please do not ship 2.6.0-final with a bug like this in it!
Felix
In article <[email protected]> (at Wed, 26 Nov 2003 09:17:45 +0100), Felix von Leitner <[email protected]> says:
Quoted 7 lines
Some digging reveals that djbdns does this (with
scope_id0):
socket(PF_INET6,...)
bind socket to ::
connect()socket to IP of peer (in this case, 210.81.13.179)send()dns query
Quoted 5 lines
at this point, the query is not sent over ppp0 as it should, but it is sent to lo. Not only that, but the queries are _received_ by the same djbdns (with servfail), although the destination IP is as said above 210.81.13.179 and none of my local IPs: 10.0.0.6, 127.0.0.1, or 217.88.123.45.
Please apply this patch.
(But I'm not sure this fix your problem...)
===== net/ipv6/udp.c 1.54 vs edited =====
net/ipv6/udp.c +1 -1
@@ -825,7 +825,7 @@struct sockaddr_in sin; sin.sin_family =AF_INET ; sin.sin_port = sin6 ? sin6->sin6_port : inet->dport; - sin.sin_addr.s_addr = daddr->s6_addr[3 ]; + sin.sin_addr.s_addr = daddr->s6_addr32[3 ]; msg->msg_name = &sin; msg->msg_namelen =sizeof (sin); do_udp_sendmsg:
Signature · 2 lines
Hideaki YOSHIFUJI @ USAGI Project <[email protected]> GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
In article <[email protected]> (at Wed, 26 Nov 2003 19:04:07 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <[email protected]> says:
Quoted 1 line
(But I'm not sure this fix your problem...)
Well, let me clarify:
I'm sure the original code has a bug.
I do think that it is related to your report
(but I don't have time to confirm it.)
s6_addr[3] should be s6_addr32[3] because the code is intended to extract IPv4 address from the IPv4-mapped address (::ffff:0.0.0.0/96) to convert sockaddr_in6{} to sockaddr_in{}.
My analysis against the report is as follows:
Because the address is IPv4-mapped address (::ffff:0.0.0.0/96) at the point, s6_addr[3] is always 0. The socket will be always connected to 0.0.0.0, which means 127.0.0.1.
The patch is definitely logically correct.
Please apply this. Thanks.
===== net/ipv6/udp.c 1.54 vs edited =====
net/ipv6/udp.c +1 -1
@@ -825,7 +825,7 @@struct sockaddr_in sin; sin.sin_family =AF_INET ; sin.sin_port = sin6 ? sin6->sin6_port : inet->dport; - sin.sin_addr.s_addr = daddr->s6_addr[3 ]; + sin.sin_addr.s_addr = daddr->s6_addr32[3 ]; msg->msg_name = &sin; msg->msg_namelen =sizeof (sin); do_udp_sendmsg:
--yoshfuji
Quoted 9 lines · On Thu, 27 Nov 2003 21:11:35 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@…
In article <[email protected]> (at Wed, 26 Nov 2003 19:04:07 +0900 (JST)), YOSHIFUJI Hideaki / _$B5HF#1QL@ <[email protected]> says:
I'm sure the original code has a bug.
I do think that it is related to your report
(but I don't have time to confirm it.)s6_addr[3] should be s6_addr32[3] because the code is intended to extract IPv4 address from the IPv4-mapped address (::ffff:0.0.0.0/96) to convert sockaddr_in6{} to sockaddr_in{}.
I know, I know.
I did apply your patch already, sorry for not telling you this.
Thanks.
A message that is not in the archive (sent off-list or not yet received): [email protected]
In article <[email protected]> (at Thu, 27 Nov 2003 17:56:20 +0100), Felix von Leitner <[email protected]> says:
Quoted 5 lines
Thus spake YOSHIFUJI Hideaki / ?$B5HF#1QL@ ([email protected]):
Quoted 2 lines
Please apply this patch.
(But I'm not sure this fix your problem...)Does not help.
really?
Quoted 2 lines
dnscache is still sending the packets out, but I don't see them in tcpdump on any interface.
Hmm...
BTW, Seeing is believing; please specify the exact source / code, setting and the log. They will help us much better than tons of descriptions.
--yoshfuji