netdev - Re: UDP does not autobind on recv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fc4ce236-7f34-601a-79f0-7ac9e087e7f9@suse.cz>
Date:   Mon, 24 Oct 2016 16:23:00 +0200
From:   Jiri Slaby <jslaby@...e.cz>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     ML netdev <netdev@...r.kernel.org>
Subject: Re: UDP does not autobind on recv

On 10/24/2016, 03:03 PM, Eric Dumazet wrote:
> On Mon, 2016-10-24 at 14:54 +0200, Jiri Slaby wrote:
>> Hello,
>>
>> as per man 7 udp:
>>   In order to receive packets, the socket can be bound to
>>   a local  address first  by using bind(2).  Otherwise,
>>   the socket layer will automatically assign a free local
>>   port out of the range defined by /proc/sys/net/ipv4
>>   /ip_local_port_range and bind the socket to INADDR_ANY.
>>
>> I did not know that bind is unneeded, so I tried that. But it does not
>> work with this piece of code:
>> int main()
>> {
>>     char buf[128];
>>     int fd = socket(AF_INET, SOCK_DGRAM, 0);
>>     recv(fd, buf, sizeof(buf), 0);
>> }
> 
> autobind makes little sense at recv() time really.
> 
> How an application could expect to receive a frame to 'some socket'
> without even knowing its port ?

For example
        struct sockaddr_storage sa;
        socklen_t slen = sizeof(sa);
        recv(fd, buf, sizeof(buf), MSG_DONTWAIT);
        getsockname(fd, (struct sockaddr *)&sa, &slen);
        recv(fd, buf, sizeof(buf), 0);
works.

> How useful would that be exactly ?

No need for finding a free port and checking, for example.

> How TCP behaves ?

TCP is a completely different story. bind is documented to be required
there. (And listen and accept.)

> I would say, fix the documentation if it is not correct.

I don't have a problem with either. I have only found, that the
implementation differs from the documentation :). Is there some
supervisor documentation (like POSIX) which should we be in conformance to?

thanks,
-- 
js
suse labs