Problem:
When connect(2) is executed, the local port number may duplicate.
How reproducible:
When using parameter "net.ipv4.ip_local_port_range", a client may use
the same port to connect to the different sessions on the localhost.
Steps to Reproduce:
1.Change "net.ipv4.ip_local_port_range".
[Example]
net.ipv4.ip_local_port_range = 32768 32770
2.Connect to any two ports of LISTEN by telnet command.
[Example]
# netstat -antp | grep LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 2828/smbd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2800/vsftpd
#
# telnet 127.0.0.1 139
# telnet 127.0.0.1 21
# telnet 127.0.0.1 21
3.Duplication of a local transmission port.
[Example]
# netstat -antp
tcp 0 0 127.0.0.1:32769 127.0.0.1:139 ESTABLISHED 18147/telnet
tcp 0 0 127.0.0.1:32769 127.0.0.1:21 ESTABLISHED 18157/telnet
Actual results:
The local port number may duplicate.
Expected results:
The local port number doesn't duplicate.
Additional info:
[Investigation]
"man 7 ip" contains following text:
-----------------------------------------------------------------
When listen(2) or connect(2) are called on an unbound socket, it
is automatically bound to a random free port with the local
address set to INADDR_ANY.
-----------------------------------------------------------------
Although indicated as "it is automatically bound to a random free
port", the port number which is not free like in a reproduce
procedure may be bound. Therefore, based on the description of
this "man 7 ip", it can be judged that it is bug to use the local
port where the process duplicated.
--- Comment by Leitner, Flavio on 2/7/2012 2:55 PM ---
It's allowed to have multiple tasks using the same port (as a
result of calling connect(2)) as long as the other connection
information (4-tuple) differs to resolve the conflict. Thus,
it must be an unique 4-tuple consisting of source and
destination IP addresses and port numbers to not conflict.
In the example, the dest port is different.
tcp 0 0 127.0.0.1:32769 127.0.0.1:139 ESTABLISHED 18147/telnet
tcp 0 0 127.0.0.1:32769 127.0.0.1:21 ESTABLISHED 18157/telnet
Reported-by: Peter Schiffer <pschiffe@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch adds documentation of several source-specific multicast
socket options that were added to kernel with implementation
of IGMPv3 in 2.5.68.
The following socket options were added:
IP_ADD_SOURCE_MEMBERSHIP
IP_DROP_SOURCE_MEMBERSHIP
IP_BLOCK_SOURCE
IP_UNBLOCK_SOURCE
IP_MSFILTER
Information Sources:
* RFC 3376 - Internet Group Management Protocol, Version 3
http://tools.ietf.org/html/rfc3376
* RFC 3678 - Socket Interface Extensions for Multicast Source
Filters
http://tools.ietf.org/html/rfc3678
* Kernel source tree
net/ipv4/ip_sockglue.c
net/ipv4/igmp.c
* Test programs used in Linux Network Stack Test
http://git.fedorahosted.org/git/?p=lnst.git
test_tools/multicast/
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Benjamin Poirier <benjamin.poirier@gmail.com>
Reported-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I noticed what appears to be a discrepancy between the ip(7)
man page and the kernel code with regards to the IP DF flag
for UDP sockets.
The man page says that "The don't-fragment flag is set on all
outgoing datagrams" and that the ip_no_pmtu_disc sysctl affects
only SOCK_STREAM sockets. This is quickly disproved by doing:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
firing up netcat and looking at a few outgoing UDP packets in
wireshark (they don't have the DF flag set).
1) in the words of `man 7 ip`:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket.
When enabled, Linux will perform Path MTU Discovery as defined
in RFC 1191 on this socket. The don't-fragment flag is set on
all outgoing datagrams. The system-wide default is controlled
by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
sockets, and disabled on all others.
2) in net/ipv4/af_inet.c:inet_create():
if (ipv4_config.no_pmtu_disc)
inet->pmtudisc = IP_PMTUDISC_DONT;
else
inet->pmtudisc = IP_PMTUDISC_WANT;
and pmtudisc is left alone from there on for UDP sockets.
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Text based on input from Lennart Poettering and Balazs Scheidler.
See https://bugzilla.kernel.org/show_bug.cgi?id=20082
Reported-by: Lennart Poettering <zxreary@0pointer.de>
Reported-by: Balazs Scheidler <bazsi@balabit.hu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page should use the type specified by POSIX,
rather than the (equivalent) type used in the kernel
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Many pages still mention use of the obsolete sysctl(2) system
call, or used the term "sysctls"; rewrite these mentions to
instead be in terms of /proc interfaces.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
PF_ constants have always had the same values; there never has
been a protocol family that had more than one address family,
and POSIX.1-2001 only specifies the AF_* constants.
PF_ constants have always had the same values; there never has
been a protocol family that had more than one address family,
and POSIX.1-2001 only specifies the AF_* constants.