Project

General

Profile

Actions

Bug #4442

open

t_bind() does not return negotiated qlen for /dev/tcp

Added by Marcel Telka about 8 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
networking
Start date:
2014-01-07
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

According to the t_bind(3nsl) man page t_bind() should return negotiated qlen (maximum number of outstanding connection indications) in ret parameter. This works properly for /dev/ticots and /dev/ticotsord, but it does not work for /dev/tcp.

The maximum number of outstanding connection indications for /dev/tcp is in tcp_conn_req_max_q and it is 128 by default:

$ ndd -get /dev/tcp tcp_conn_req_max_q
128
$

Here is the testcase shoving the t_bind() does not work as expected and documented for /dev/tcp:

$ cat t_bind-test.c 
#include <xti.h>
#include <fcntl.h>
#include <stdio.h>

int
main(int argc, char **argv)
{
    int fd;
    struct t_info tinfo;
    struct t_bind req;
    struct t_bind ret;
    unsigned q;

    if (argc != 3) {
        printf("Wrong arguments\\n");
        return 1;
    }

    q = atoi(argv[2]);

    fd = t_open(argv[1], O_RDWR, &tinfo);
    if (fd == -1) {
        printf("t_open failed\\n");
        return 1;
    }

    req.addr.len = 0;
    req.qlen = q;

    ret.addr.maxlen = 0;

    if (t_bind(fd, &req, &ret) != 0) {
        printf("t_bind failed\\n");
        return 1;
    }

    printf("negotiated qlen: %d\\n", ret.qlen);

    return 0;
}
$ gcc -lnsl -o t_bind-test t_bind-test.c
$ ./t_bind-test /dev/ticots 10000
negotiated qlen: 4096
$ ./t_bind-test /dev/ticotsord 10000
negotiated qlen: 4096
$ ./t_bind-test /dev/ticlts 10000
negotiated qlen: 0
$ ./t_bind-test /dev/tcp 10000
negotiated qlen: 10000
$ ./t_bind-test /dev/udp 10000
negotiated qlen: 10000
$

The expected result for /dev/tcp above is 128.

Actions #1

Updated by Sachidananda Urs over 6 years ago

Marcel,

Man page says:

       The qlen field has meaning only when initializing a connection-mode                          
       service. It specifies the number of outstanding connection indications                       
       that the transport provider should support for the given transport                           
       endpoint. An outstanding connection indication is one that has been                          
       passed to the transport user by the transport provider but which has                         
       not been accepted or rejected. A value of qlen greater than zero is                          
       only meaningful when issued by a passive transport user that expects                         
       other users to call it. The value of qlen will be negotiated by the                          
       transport provider and may be changed if the transport provider cannot                       
       support the specified number of outstanding connection indications.                          
       However, this value of qlen will never be negotiated from a requested                        
       value greater than zero to zero. This is a requirement on transport                          
       providers; see WARNINGS below. On return, the qlen field in ret will                         
       contain the negotiated value.          

And the ipadm command output:

root@odin:/export/home/sac/tmp/4442# ipadm set-prop -p _conn_req_max_q=1024 tcp
root@odin:/export/home/sac/tmp/4442# ipadm show-prop -p _conn_req_max_q tcp
PROTO PROPERTY              PERM CURRENT      PERSISTENT   DEFAULT      POSSIBLE
tcp   _conn_req_max_q       rw   1024         1024         128          1-4294967295
root@odin:/export/home/sac/tmp/4442# ipadm set-prop -p _conn_req_max_q=4294967295 tcp
root@odin:/export/home/sac/tmp/4442# ipadm show-prop -p _conn_req_max_q tcp
PROTO PROPERTY              PERM CURRENT      PERSISTENT   DEFAULT      POSSIBLE
tcp   _conn_req_max_q       rw   4294967295   4294967295   128          1-4294967295
root@odin:/export/home/sac/tmp/4442# 

It matches your reproducer program output, i.e negotiated qlen is 1000, and the transport end-point
supports so many outstanding connection indications.

I may be wrong, I was just trying to figure this out. Please correct me if I'm missing something.

Actions #2

Updated by Marcel Telka over 6 years ago

Sachidananda Urs wrote:

It matches your reproducer program output, i.e negotiated qlen is 1000, and the transport end-point
supports so many outstanding connection indications.

I do not see 1000 neither in your output, nor in my testcase. I do not understand what exactly you are trying to show using the ipadm commands. Please elaborate. Thanks.

Actions #3

Updated by Sachidananda Urs over 6 years ago

Hi Marcel,

I thought, ret.qlen would have the negotiated qlen, and for tcp valid range is 1-4294967295. And thought 10000 in your t_bind reproducer program was a valid return value.

I will dig more on this and get back to you. Please ignore this for now.

Actions #4

Updated by Marcel Telka over 6 years ago

Sachidananda Urs wrote:

I thought, ret.qlen would have the negotiated qlen, and for tcp valid range is 1-4294967295. And thought 10000 in your t_bind reproducer program was a valid return value.

Yes, the ret.qlen would have the negotiated qlen. The problem is that tcp_conn_req_max_q contains the max value of the negotiated qlen (for TCP), so any negotation cannot exceed this value (128 by default). Since we do see the "negotiated" qlen as 10000 (while the max is 128), it means that either the TCP was able to negotiate higher value than the max (I believe this is not the case), or t_bind() does not return the actually negotiated qlen, but instead it automatically returns the requested qlen, even the negotiated qlen is different (I believe this is the problem).

Actions

Also available in: Atom PDF