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 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).