From: Octavian Purdila <opurdila@ixiacom.com>
To: netdev@vger.kernel.org
Subject: ports beeing reused too fast
Date: Fri, 8 May 2009 23:11:09 +0300 [thread overview]
Message-ID: <200905082311.09414.opurdila@ixiacom.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
Hi,
We've been running into an issue where a firewall would drop packets when an
moderate (~360) connection rate was going through it. It looks like the
firewall is dropping the SYNs that reuse ports "too fast".
We have no issues with Linux 2.6.7, so I guess the behavior changed because of
this this commit:
commit 6df716340da3a6fdd33d73d7ed4c6f7590ca1c42
Author: Stephen Hemminger <shemminger@osdl.org>
Date: Thu Nov 3 16:33:23 2005 -0800
[TCP/DCCP]: Randomize port selection
Now, I did some tests to confirm my suspicion. Basically, I am simulating a
connection rate test (I've attached the .c to this email) by opening up
connections and closing them - one at a time, and noting down the ports used,
then looking for duplicate ports and printing the distance between the
connection no.
Here is one of the runs, which make 1000 iterations:
listening (port 1242)
port reused: 38203: distance 578 (624,46)
port reused: 55693: distance 85 (147,62)
port reused: 38269: distance 803 (872,69)
port reused: 46239: distance 249 (344,95)
port reused: 40981: distance 215 (319,104)
port reused: 46246: distance 524 (641,117)
port reused: 43990: distance 378 (498,120)
port reused: 53766: distance 52 (232,180)
port reused: 44199: distance 194 (383,189)
port reused: 59464: distance 173 (384,211)
port reused: 44417: distance 264 (492,228)
port reused: 56989: distance 229 (553,324)
port reused: 60117: distance 69 (394,325)
port reused: 44549: distance 179 (566,387)
port reused: 39213: distance 300 (801,501)
port reused: 60166: distance 152 (671,519)
port reused: 44178: distance 108 (712,604)
port reused: 46516: distance 6 (792,786)
port reused: 55754: distance 95 (969,874)
19 ports were being reused
Running the same test on 2.6.7 yields a "0 ports were being reused" on all
tests that I've ran (10 or so).
Isn't it desirable to have the behavior from 2.6.7?
I've looked over the code and it looks right, so maybe net_random() is not
random enough? Or maybe there are side effects because of the % port_range?
Thanks,
tavi
[-- Attachment #2: port-reuse.c --]
[-- Type: text/x-csrc, Size: 2365 bytes --]
#include <stdio.h>
#include <sys/types.h>
#include <netinet/ip.h>
#include <sys/socket.h>
#include <unistd.h>
#define N 1000
int ports[N], listen_port = 1234;
/* find duplicate ports and show distance between them */
int analyze(void)
{
int i, j, n = 0;
for(i = 0; i < N; i++) {
for(j = i + 1; j < N; j++) {
if (ports[i] != ports[j])
continue;
printf(" port reused: %d: distance %d (%d,%d)\n", ports[i], j-i, j, i);
n++;
}
}
printf("%d ports were being reused\n", n);
return 0;
}
int client(void)
{
int sock, i = 0;
size_t tmp;
struct sockaddr_in addr_bind = {
.sin_family = AF_INET,
.sin_addr.s_addr = INADDR_ANY,
.sin_port = 0,
}, addr_connect = {
.sin_family = AF_INET,
.sin_addr.s_addr = htonl(0x7f000001),
.sin_port = htons(listen_port),
}, addr_sockname;
sleep(1);
loop:
sock = socket(AF_INET, SOCK_STREAM, 0);
if (!sock) {
perror("client: failed to create socket");
return -1;
}
if (bind(sock, (struct sockaddr*)&addr_bind, sizeof(addr_bind)) < 0) {
perror("client: failed to bind");
return -1;
}
tmp = sizeof(addr_sockname);
if (getsockname(sock, (struct sockaddr*)&addr_sockname, &tmp) < 0) {
perror("client: getsockname failed");
return -1;
}
ports[i] = ntohs(addr_sockname.sin_port);
if (connect(sock, (struct sockaddr*)&addr_connect, sizeof(addr_connect)) < 0) {
perror("client: failed to connect");
return -1;
}
if (read(sock, &tmp, sizeof(tmp)) != 0) {
perror("read failed");
return -1;
}
close(sock);
if (++i < N)
goto loop;
return analyze();
}
int server(void)
{
int sock = socket(AF_INET, SOCK_STREAM, 0), sock2;
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_addr.s_addr = INADDR_ANY,
};
again:
addr.sin_port = htons(listen_port);
if (!sock) {
perror("server: failed to create socket");
return -1;
}
if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
perror("server: failed to bind");
listen_port++;
goto again;
}
if (listen(sock, 128) < 0) {
perror("server: failed to listen");
return -1;
}
printf("listening (port %d)\n", listen_port);
switch (fork()) {
case -1:
return -1;
case 0:
return client();
}
loop:
sock2 = accept(sock, NULL, NULL);
if (sock2 < 0) {
perror("server: accept failed\n");
return -1;
}
close(sock2);
goto loop;
}
int main()
{
return server();
}
next reply other threads:[~2009-05-08 20:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-08 20:11 Octavian Purdila [this message]
2009-05-09 6:58 ` ports beeing reused too fast Eric Dumazet
2009-05-09 13:11 ` Octavian Purdila
2009-05-09 15:17 ` Eric Dumazet
2009-05-09 16:16 ` Eric Dumazet
2009-05-09 19:31 ` Bill Fink
2009-05-09 19:41 ` Octavian Purdila
2009-05-09 22:45 ` Stephen Hemminger
2009-05-12 12:32 ` Octavian Purdila
2009-05-12 15:11 ` Stephen Hemminger
2009-05-12 15:52 ` Octavian Purdila
2009-05-14 20:29 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200905082311.09414.opurdila@ixiacom.com \
--to=opurdila@ixiacom.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).