Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On 6/27/2018 3:07 AM, Ka-Cheong Poon wrote: On 06/26/2018 09:08 PM, Sowmini Varadhan wrote: On (06/26/18 21:02), Ka-Cheong Poon wrote: [...] I don't expect RDS apps will want to use link local address in the first place. In fact, most normal network apps don't. This is not true. You're not doing this for IPv4 and RDS today (you dont have to do this for UDP, afaik) Do you know of any IPv4 RDS app which uses IPv4 link local address? In fact, IPv4 link local address is explicitly disallowed for active active bonding. Yes. Cluster-ware HAIP makes use of link local addresses. That check was mainly because of RDMA CM issues but that only means active-active isn't used. The bonding works just fine and if needed cluster-ware can also use TCP transport. Lets not add this new behavior for link local and its actually not relevant to really v6 addressing support. Regards, Santosh
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On (06/27/18 18:07), Ka-Cheong Poon wrote: > > There is a reason for that. It is the way folks expect > how IPv6 addresses are being used. have you tried "traceoute6 -s abc::2 fe80::2" on linux? > It is not just forwarding. The simple case is that one > picks a global address in a different link and then > use it to send to a link local address in another link. This is actually not any different than ipv4's strong/weak ES model. Global addresses are supposed to be globally routable. For your above example, if yuu do that, it is assumed that your routing table has been set up suitably. To state what may be well-known: This does not work for link-locals, becuase, as the name suggests, those are local to the link and you may have the same link-local on multiple links > This does not work. And the RDS connection created will > be stuck forever. that is a different problem in the RDS implementation (that it does not backoff and timeout a failing reconnect) As you can see from the traceroute6 example, global <-> link-local is supported for udp (and probably also tcp sockets, I have not checked that case) > I don't expect RDS apps will want to use link local address > in the first place. In fact, most normal network apps don't. : > Do you know of any IPv4 RDS app which uses IPv4 link local > address? In fact, IPv4 link local address is explicitly > disallowed for active active bonding. Are we talking about "why this ok for my particular use of link-local, so I can slide my patch forward" or, "why this is correct IPv6 behavior"? > Can you explain why DNS name resolution will return an IPv6 > link local address? I'm surprised if it actually does. It depends on how you set up your DNS. It seems like this is all about "I dont want to deal with this now", so I dont want to continue this discussion which is really going nowhere. Thanks --Sowmini
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On 06/26/2018 09:08 PM, Sowmini Varadhan wrote: On (06/26/18 21:02), Ka-Cheong Poon wrote: In this case, RFC 6724 prefers link local address as source. the keyword is "prefers". There is a reason for that. It is the way folks expect how IPv6 addresses are being used. While using non-link local address (say ULA) is not forbidden, doing this can easily cause inter-operability issues (does the app really know that the non-link local source and the link local destination addresses are really on the same link?). I think it is prudent to disallow this in RDS unless there is a very clear and important reason to do so. I remember the issues that triggered 6724. The "interop" issue is that when you send from Link-local to global, and need forwarding, it may not work. It is not just forwarding. The simple case is that one picks a global address in a different link and then use it to send to a link local address in another link. This does not work. And the RDS connection created will be stuck forever. I don't think this is a good idea to have such stuck connections. but I dont think an RDS application today expects to deal with the case that "oh I got back and error when I tried to send to address X on rds socket rs1, let me go and check what I am bound to, and maybe create another socket, and bind it to link-local" I don't expect RDS apps will want to use link local address in the first place. In fact, most normal network apps don't. You're not doing this for IPv4 and RDS today (you dont have to do this for UDP, afaik) Do you know of any IPv4 RDS app which uses IPv4 link local address? In fact, IPv4 link local address is explicitly disallowed for active active bonding. This is especially true if "X" is a hostname that got resovled using DNS Can you explain why DNS name resolution will return an IPv6 link local address? I'm surprised if it actually does. BTW, if it is really > needed, it can be added in future. shrug. You are introducing a new error return. An error needs to be returned because it is not allowed. -- K. Poon ka-cheong.p...@oracle.com
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On (06/26/18 21:02), Ka-Cheong Poon wrote: > > In this case, RFC 6724 prefers link local address as source. the keyword is "prefers". > While using non-link local address (say ULA) is not forbidden, > doing this can easily cause inter-operability issues (does the > app really know that the non-link local source and the link > local destination addresses are really on the same link?). I > think it is prudent to disallow this in RDS unless there is a > very clear and important reason to do so. I remember the issues that triggered 6724. The "interop" issue is that when you send from Link-local to global, and need forwarding, it may not work. but I dont think an RDS application today expects to deal with the case that "oh I got back and error when I tried to send to address X on rds socket rs1, let me go and check what I am bound to, and maybe create another socket, and bind it to link-local" You're not doing this for IPv4 and RDS today (you dont have to do this for UDP, afaik) This is especially true if "X" is a hostname that got resovled using DNS > BTW, if it is really > needed, it can be added in future. shrug. You are introducing a new error return. --Sowmini
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On 06/26/2018 06:16 PM, Sowmini Varadhan wrote: On (06/26/18 13:30), Ka-Cheong Poon wrote: My answer to this is that if a socket is not bound to a link local address (meaning it is bound to a non-link local address) and it is used to send to a link local peer, I think it should fail. Hmm, I'm not sure I agree. I dont think this is forbidden by RFC 6724 - yes, such a packet cannot be forwarded, but if everything is on the same link, and the dest only has a link-local, you should not need to (create and) bind another socket to a link-local to talk to this destination.. In this case, RFC 6724 prefers link local address as source. While using non-link local address (say ULA) is not forbidden, doing this can easily cause inter-operability issues (does the app really know that the non-link local source and the link local destination addresses are really on the same link?). I think it is prudent to disallow this in RDS unless there is a very clear and important reason to do so. BTW, if it is really needed, it can be added in future. This is consistent with the scope_id check I mentioned in the previous mail. If the socket is not bound to a link local address, the bound_scope_id is 0. So if the socket is used to send to a link local address (which has a non-zero scope_id), the check will catch it and fail the call. A new conn should not be created in this case. -- K. Poon ka-cheong.p...@oracle.com
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On (06/26/18 13:30), Ka-Cheong Poon wrote: > > My answer to this is that if a socket is not bound to a link > local address (meaning it is bound to a non-link local address) > and it is used to send to a link local peer, I think it should > fail. Hmm, I'm not sure I agree. I dont think this is forbidden by RFC 6724 - yes, such a packet cannot be forwarded, but if everything is on the same link, and the dest only has a link-local, you should not need to (create and) bind another socket to a link-local to talk to this destination.. > This is consistent with the scope_id check I mentioned in > the previous mail. If the socket is not bound to a link local > address, the bound_scope_id is 0. So if the socket is used to > send to a link local address (which has a non-zero scope_id), the > check will catch it and fail the call. A new conn should not > be created in this case.
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On 06/26/2018 01:50 AM, Sowmini Varadhan wrote:
If a socket is bound, I guess the scope_id should be used. So
if a socket is not bound to a link local address and the socket
is used to sent to a link local peer, it should fail.
PF_RDS sockets *MUST* alwasy be bound. See
Documentation/networking/rds.txt:
" Sockets must be bound before you can send or receive data.
This is needed because binding also selects a transport and
attaches it to the socket. Once bound, the transport assignment
does not change."
Also, rds_sendmsg checks this (from net-next, your version
has the equivalent ipv6_addr_any etc check):
if (daddr == 0 || rs->rs_bound_addr == 0) {
release_sock(sk);
ret = -ENOTCONN; /* XXX not a great errno */
goto out;
}
I think you misunderstood what I wrote. The above is in response
to your original question:
--
> And this is even more confusing because the fastpath in rds_sendmsg
> does not take the bound_scope_id into consideration at all:
> 1213 if (rs->rs_conn &&
ipv6_addr_equal(>rs_conn->c_faddr, ))
> 1214 conn = rs->rs_conn;
> 1215 else {
> 1216 conn = rds_conn_create_outgoing( /* .. */, scope_id)
> so if I erroneously passed a msg_name on a connected rds socket, what
> would happen? (see also question about rds_connect() itself, below)
--
My answer to this is that if a socket is not bound to a link
local address (meaning it is bound to a non-link local address)
and it is used to send to a link local peer, I think it should
fail. This is consistent with the scope_id check I mentioned in
the previous mail. If the socket is not bound to a link local
address, the bound_scope_id is 0. So if the socket is used to
send to a link local address (which has a non-zero scope_id), the
check will catch it and fail the call. A new conn should not
be created in this case.
--
K. Poon
ka-cheong.p...@oracle.com
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On 6/25/2018 10:50 AM, Sowmini Varadhan wrote: On (06/26/18 01:43), Ka-Cheong Poon wrote: Yes, I think if the socket is bound, it should check the scope_id in msg_name (if not NULL) to make sure that they match. A bound RDS socket can send to multiple peers. But if the bound local address is link local, it should only be allowed to send to peers on the same link. agree. Yep. Its inline with RDS bind behavior. If a socket is bound, I guess the scope_id should be used. So if a socket is not bound to a link local address and the socket is used to sent to a link local peer, it should fail. PF_RDS sockets *MUST* alwasy be bound. See Documentation/networking/rds.txt: " Sockets must be bound before you can send or receive data. This is needed because binding also selects a transport and attaches it to the socket. Once bound, the transport assignment does not change." In any case link local or not, the socket needs to be bound before any data can be sent as documented. Send path already enforces it. Also, why is there no IPv6 support in rds_connect? Oops, I missed this when I ported the internal version to the net-next version. Will add it back. So the net-next wasn't tested? IPv6 connections itself wouldn't be formed with this missing. As mentioned already, please test v2 before posting on list. Regards, Santosh
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On (06/26/18 01:43), Ka-Cheong Poon wrote:
>
> Yes, I think if the socket is bound, it should check the scope_id
> in msg_name (if not NULL) to make sure that they match. A bound
> RDS socket can send to multiple peers. But if the bound local
> address is link local, it should only be allowed to send to peers
> on the same link.
agree.
> If a socket is bound, I guess the scope_id should be used. So
> if a socket is not bound to a link local address and the socket
> is used to sent to a link local peer, it should fail.
PF_RDS sockets *MUST* alwasy be bound. See
Documentation/networking/rds.txt:
" Sockets must be bound before you can send or receive data.
This is needed because binding also selects a transport and
attaches it to the socket. Once bound, the transport assignment
does not change."
Also, rds_sendmsg checks this (from net-next, your version
has the equivalent ipv6_addr_any etc check):
if (daddr == 0 || rs->rs_bound_addr == 0) {
release_sock(sk);
ret = -ENOTCONN; /* XXX not a great errno */
goto out;
}
>
> >Also, why is there no IPv6 support in rds_connect?
>
>
> Oops, I missed this when I ported the internal version to the
> net-next version. Will add it back.
Ok
--Sowmini
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On 06/26/2018 01:03 AM, Sowmini Varadhan wrote:
On (06/25/18 03:38), Ka-Cheong Poon wrote:
@@ -1105,8 +1105,27 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg,
size_t payload_len)
break;
case sizeof(*sin6): {
- ret = -EPROTONOSUPPORT;
- goto out;
+ int addr_type;
:
:
+ daddr = sin6->sin6_addr;
+ dport = sin6->sin6_port;
+ scope_id = sin6->sin6_scope_id;
+ break;
}
In rds_sendmsg, the scopeid passed to rds_conn_create_outgoing
may come from the msg_name (if msg_name is a link-local) or
may come from the rs_bound_scope_id (for connected socket, change
made in Patch 1 of the series).
This sounds inconsistent.
If I bind to scopeid if1 and then send to fe80::1%if2 (without connect()),
we'd create an rds_connection with dev_if set to if2.
(first off, its a bit unexpected to be sending to fe80::1%if2 when you
are bound to a link-local on if1!)
But then, if we got back a response from fe80::1%if2, I think we would
not find a matching conn in rds_recv_incoming?
Yes, I think if the socket is bound, it should check the scope_id
in msg_name (if not NULL) to make sure that they match. A bound
RDS socket can send to multiple peers. But if the bound local
address is link local, it should only be allowed to send to peers
on the same link.
And this is even more confusing because the fastpath in rds_sendmsg
does not take the bound_scope_id into consideration at all:
1213 if (rs->rs_conn && ipv6_addr_equal(>rs_conn->c_faddr, ))
1214 conn = rs->rs_conn;
1215 else {
1216 conn = rds_conn_create_outgoing( /* .. */, scope_id)
so if I erroneously passed a msg_name on a connected rds socket, what
would happen? (see also question about rds_connect() itself, below)
The check added above takes care of this. The scope_id should
match.
Should we always use rs_bound_scope_id for creating the outgoing
rds_connection? (you may need something deterministic for this,
like "if bound addr is linklocal, return error if daddr has a different
scopeid, else use the bound addr's scopeid", plus, "if bound addr is
not global, and daddr is link-local, we need a conn with the daddr's
scopeid")
If a socket is bound, I guess the scope_id should be used. So
if a socket is not bound to a link local address and the socket
is used to sent to a link local peer, it should fail.
Also, why is there no IPv6 support in rds_connect?
Oops, I missed this when I ported the internal version to the
net-next version. Will add it back.
--
K. Poon
ka-cheong.p...@oracle.com
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
On (06/25/18 03:38), Ka-Cheong Poon wrote:
> @@ -1105,8 +1105,27 @@ int rds_sendmsg(struct socket *sock, struct msghdr
> *msg, size_t payload_len)
> break;
>
> case sizeof(*sin6): {
> - ret = -EPROTONOSUPPORT;
> - goto out;
> + int addr_type;
:
:
> + daddr = sin6->sin6_addr;
> + dport = sin6->sin6_port;
> + scope_id = sin6->sin6_scope_id;
> + break;
> }
In rds_sendmsg, the scopeid passed to rds_conn_create_outgoing
may come from the msg_name (if msg_name is a link-local) or
may come from the rs_bound_scope_id (for connected socket, change
made in Patch 1 of the series).
This sounds inconsistent.
If I bind to scopeid if1 and then send to fe80::1%if2 (without connect()),
we'd create an rds_connection with dev_if set to if2.
(first off, its a bit unexpected to be sending to fe80::1%if2 when you
are bound to a link-local on if1!)
But then, if we got back a response from fe80::1%if2, I think we would
not find a matching conn in rds_recv_incoming?
And this is even more confusing because the fastpath in rds_sendmsg
does not take the bound_scope_id into consideration at all:
1213 if (rs->rs_conn && ipv6_addr_equal(>rs_conn->c_faddr, ))
1214 conn = rs->rs_conn;
1215 else {
1216 conn = rds_conn_create_outgoing( /* .. */, scope_id)
so if I erroneously passed a msg_name on a connected rds socket, what
would happen? (see also question about rds_connect() itself, below)
Should we always use rs_bound_scope_id for creating the outgoing
rds_connection? (you may need something deterministic for this,
like "if bound addr is linklocal, return error if daddr has a different
scopeid, else use the bound addr's scopeid", plus, "if bound addr is
not global, and daddr is link-local, we need a conn with the daddr's
scopeid")
Also, why is there no IPv6 support in rds_connect?
(still looking through the rds-tcp changes, but wanted to get these
questions clarified first).
--Sowmini
Re: [PATCH net-next 2/3] rds: Enable RDS IPv6 support
Hi Ka-Cheong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Ka-Cheong-Poon/rds-IPv6-support/20180625-190047
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
net/rds/tcp_listen.c:86:22: sparse: expression using sizeof(void)
>> net/rds/tcp_listen.c:288:33: sparse: incorrect type in assignment (different
>> base types) @@expected restricted __be16 [usertype] sin6_port @@got
>> unsignedrestricted __be16 [usertype] sin6_port @@
net/rds/tcp_listen.c:288:33:expected restricted __be16 [usertype]
sin6_port
net/rds/tcp_listen.c:288:33:got unsigned short [unsigned] [usertype]
>> net/rds/tcp_listen.c:295:38: sparse: incorrect type in assignment (different
>> base types) @@expected restricted __be32 [usertype] s_addr @@got
>> ricted __be32 [usertype] s_addr @@
net/rds/tcp_listen.c:295:38:expected restricted __be32 [usertype] s_addr
net/rds/tcp_listen.c:295:38:got unsigned long [unsigned]
>> net/rds/tcp_listen.c:296:31: sparse: incorrect type in assignment (different
>> base types) @@expected restricted __be16 [usertype] sin_port @@got
>> unsignedrestricted __be16 [usertype] sin_port @@
net/rds/tcp_listen.c:296:31:expected restricted __be16 [usertype]
sin_port
net/rds/tcp_listen.c:296:31:got unsigned short [unsigned] [usertype]
vim +288 net/rds/tcp_listen.c
258
259 struct socket *rds_tcp_listen_init(struct net *net, bool isv6)
260 {
261 struct socket *sock = NULL;
262 struct sockaddr_storage ss;
263 struct sockaddr_in6 *sin6;
264 struct sockaddr_in *sin;
265 int addr_len;
266 int ret;
267
268 ret = sock_create_kern(net, isv6 ? PF_INET6 : PF_INET,
SOCK_STREAM,
269 IPPROTO_TCP, );
270 if (ret < 0) {
271 rdsdebug("could not create %s listener socket: %d\n",
272 isv6 ? "IPv6" : "IPv4", ret);
273 goto out;
274 }
275
276 sock->sk->sk_reuse = SK_CAN_REUSE;
277 rds_tcp_nonagle(sock);
278
279 write_lock_bh(>sk->sk_callback_lock);
280 sock->sk->sk_user_data = sock->sk->sk_data_ready;
281 sock->sk->sk_data_ready = rds_tcp_listen_data_ready;
282 write_unlock_bh(>sk->sk_callback_lock);
283
284 if (isv6) {
285 sin6 = (struct sockaddr_in6 *)
286 sin6->sin6_family = PF_INET6;
287 sin6->sin6_addr = in6addr_any;
> 288 sin6->sin6_port = (__force u16)htons(RDS_TCP_PORT);
289 sin6->sin6_scope_id = 0;
290 sin6->sin6_flowinfo = 0;
291 addr_len = sizeof(*sin6);
292 } else {
293 sin = (struct sockaddr_in *)
294 sin->sin_family = PF_INET;
> 295 sin->sin_addr.s_addr = INADDR_ANY;
> 296 sin->sin_port = (__force u16)htons(RDS_TCP_PORT);
297 addr_len = sizeof(*sin);
298 }
299
300 ret = sock->ops->bind(sock, (struct sockaddr *), addr_len);
301 if (ret < 0) {
302 rdsdebug("could not bind %s listener socket: %d\n",
303 isv6 ? "IPv6" : "IPv4", ret);
304 goto out;
305 }
306
307 ret = sock->ops->listen(sock, 64);
308 if (ret < 0)
309 goto out;
310
311 return sock;
312 out:
313 if (sock)
314 sock_release(sock);
315 return NULL;
316 }
317
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH net-next 2/3] rds: Enable RDS IPv6 support
This patch enables RDS to use IPv6 addresses. For RDS/TCP, the
listener is now an IPv6 endpoint which accepts both IPv4 and IPv6
connection requests. RDS/RDMA/IB uses a private data (struct
rds_ib_connect_private) exchange between endpoints at RDS connection
establishment time to support RDMA. This private data exchange uses a
32 bit integer to represent an IP address. This needs to be changed in
order to support IPv6. A new private data struct
rds6_ib_connect_private is introduced to handle this. To ensure
backward compatibility, an IPv6 capable RDS stack uses another RDMA
listener port (RDS_CM_PORT) to accept IPv6 connection. And it
continues to use the original RDS_PORT for IPv4 RDS connections. When
it needs to communicate with an IPv6 peer, it uses the RDS_CM_PORT to
send the connection set up request.
Signed-off-by: Ka-Cheong Poon
---
net/rds/bind.c | 21 +++---
net/rds/connection.c | 43 -
net/rds/ib.c | 55 +---
net/rds/ib_cm.c | 15 +++--
net/rds/rdma_transport.c | 32 ++--
net/rds/rdma_transport.h | 2 ++
net/rds/rds.h| 12 ++-
net/rds/send.c | 23 ++--
net/rds/tcp.c| 54 +--
net/rds/tcp.h| 4 +---
net/rds/tcp_connect.c| 54 ---
net/rds/tcp_listen.c | 40 +++
12 files changed, 269 insertions(+), 86 deletions(-)
diff --git a/net/rds/bind.c b/net/rds/bind.c
index 3a1097e..4c2bf9c 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -164,11 +164,12 @@ int rds_bind(struct socket *sock, struct sockaddr *uaddr,
int addr_len)
struct in6_addr v6addr, *binding_addr;
struct rds_transport *trans;
__u32 scope_id = 0;
+ int addr_type;
int ret = 0;
__be16 port;
- /* We only allow an RDS socket to be bound to and IPv4 address. IPv6
-* address support will be added later.
+ /* We allow an RDS socket to be bound to either IPv4 or IPv6
+* address.
*/
if (addr_len == sizeof(struct sockaddr_in)) {
struct sockaddr_in *sin = (struct sockaddr_in *)uaddr;
@@ -180,7 +181,21 @@ int rds_bind(struct socket *sock, struct sockaddr *uaddr,
int addr_len)
binding_addr =
port = sin->sin_port;
} else if (addr_len == sizeof(struct sockaddr_in6)) {
- return -EPROTONOSUPPORT;
+ struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)uaddr;
+
+ addr_type = ipv6_addr_type(>sin6_addr);
+ if (sin6->sin6_family != AF_INET6 ||
+ !(addr_type & IPV6_ADDR_UNICAST)) {
+ return -EINVAL;
+ }
+ /* The scope ID must be specified for link local address. */
+ if (addr_type & IPV6_ADDR_LINKLOCAL) {
+ if (sin6->sin6_scope_id == 0)
+ return -EINVAL;
+ scope_id = sin6->sin6_scope_id;
+ }
+ binding_addr = >sin6_addr;
+ port = sin6->sin6_port;
} else {
return -EINVAL;
}
diff --git a/net/rds/connection.c b/net/rds/connection.c
index ca72563..8c5d093 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2006, 2017 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -486,10 +486,17 @@ void rds_conn_destroy(struct rds_connection *conn)
}
EXPORT_SYMBOL_GPL(rds_conn_destroy);
-static void rds_conn_message_info(struct socket *sock, unsigned int len,
- struct rds_info_iterator *iter,
- struct rds_info_lengths *lens,
- int want_send)
+static void __rds_inc_msg_cp(struct rds_incoming *inc,
+struct rds_info_iterator *iter,
+void *saddr, void *daddr, int flip)
+{
+ rds_inc_info_copy(inc, iter, *(__be32 *)saddr, *(__be32 *)daddr, flip);
+}
+
+static void rds_conn_message_info_cmn(struct socket *sock, unsigned int len,
+ struct rds_info_iterator *iter,
+ struct rds_info_lengths *lens,
+ int want_send)
{
struct hlist_head *head;
struct list_head *list;
@@ -524,18 +531,13 @@ static void rds_conn_message_info(struct socket *sock,
unsigned int len,
/* XXX too lazy to maintain counts.. */
