netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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