From: Casey Carter <ccarter@cs.uiuc.edu>
To: Kevin Dwyer <kevin@pheared.net>
Cc: Casey Carter <Casey@Carter.net>,
netdev@oss.sgi.com, linux-ha@lists.linux-ha.org
Subject: Re: Strange UDP binding behavior (SO_BINDTODEVICE)
Date: Tue, 07 Oct 2003 15:51:57 -0500 [thread overview]
Message-ID: <3F83276D.3070700@cs.uiuc.edu> (raw)
In-Reply-To: <20031006210600.37da62c9.kevin@pheared.net>
Kevin Dwyer wrote:
>On Mon, 06 Oct 2003 17:50:53 -0500
>Casey Carter <Casey@Carter.net> wrote:
>
>
>
>>This is not a bug, it's a feature! It is possible to use multiple
>>sockets with the same port number bound to different interfaces (where
>>"no interface" is one possible choice). The UDP packet delivery code
>>favors the socket that is bound to the interface through which packets
>>are received. So, if I am only interested in packets for port 6666 on
>>eth1, then I am prioritized ahead of the socket bound to "no
>>interface" port 6666.
>>
>>
>
>Well, I would buy that as reasonable, acceptable behavior, but I think
>the reverse is true.
>
>We are binding specifically to say, eth0 on port 694. Someone comes
>along and binds to "no interface" on port 694 and trumps our socket.
>Isn't that the opposite of what you describe?
>
>
Taking a look at the UDP delivery code in net/ipv4/udp.c (version
2.6.0-test6) we see:
struct sock *udp_v4_lookup_longway(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif)
{
struct sock *sk, *result = NULL;
struct hlist_node *node;
unsigned short hnum = ntohs(dport);
int badness = -1;
sk_for_each(sk, node, &udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]) {
struct inet_opt *inet = inet_sk(sk);
if (inet->num == hnum && !ipv6_only_sock(sk)) {
int score = (sk->sk_family == PF_INET ? 1 : 0);
if (inet->rcv_saddr) {
if (inet->rcv_saddr != daddr)
continue;
score+=2;
}
if (inet->daddr) {
if (inet->daddr != saddr)
continue;
score+=2;
}
if (inet->dport) {
if (inet->dport != sport)
continue;
score+=2;
}
if (sk->sk_bound_dev_if) {
if (sk->sk_bound_dev_if != dif)
continue;
score+=2;
}
if(score == 9) {
result = sk;
break;
} else if(score > badness) {
result = sk;
badness = score;
}
}
}
return result;
}
This code picks a UDP socket to deliver to, amongst those with the
correct destination port number. It does so by ranking each socket on a
scale from 0 to 9 and picking the first socket with the best score.
Since the score increments are all 2, this code weights equally a socket
that is bound to the correct interface and (for example) a socket bound
to no interface but bound to the specific IP address the packet is
addressed to. IMHO, the delivery should weigh sk_bound_dev_if much more
strongly (7 instead of 2), so that if-bound sockets are always favored
over non-if-bound. I would be happy to submit the (trivial) patch to do
so if the networking gurus agree?
--
Casey Carter
Casey@Carter.net
ccarter@cs.uiuc.edu
AIM: cartec69
next prev parent reply other threads:[~2003-10-07 20:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-05 17:01 Strange UDP binding behavior (SO_BINDTODEVICE) Kevin Dwyer
2003-10-06 22:50 ` Casey Carter
2003-10-07 1:06 ` Kevin Dwyer
2003-10-07 20:51 ` Casey Carter [this message]
2003-10-07 21:08 ` Kevin Dwyer
2003-10-07 21:49 ` Casey Carter
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=3F83276D.3070700@cs.uiuc.edu \
--to=ccarter@cs.uiuc.edu \
--cc=Casey@Carter.net \
--cc=kevin@pheared.net \
--cc=linux-ha@lists.linux-ha.org \
--cc=netdev@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.