Re: Q: UDP Broadcast, Sockets, Dual NICs, Single Cable

On 16.12.10 5:14 , Jack Dao wrote:
>
>
> HI, I have a system with dual NICs - eth0 and eth1. eth0 is live (has
> an IP address and a cable from it's RJ45 jack into the wall). eth0 is
> not 'live' (no IP address, and no cable).
>
> So I have an application that opens 2 UDP sockets, one on eth0 and the
> other on eth1. It then sits awaiting for broadcast messages from
> clients. When it gets one, we process it. Here's what's strange: When
> a broadcast messages comes in, we also get the message on the socket
> associated with eth1 (the NIC with no IP address and no cable).
>
> Are UDP broadcast message known to behave in this way? Could this be a
> bug in the Linux IP stack? A but on our application?
>
> Any feedback appreciated.


How do you associate a socket with an interface?

--

Tauno Voipio
tauno voipio (at) iki fi

On Thu, 2010-12-16, Tauno Voipio wrote:
> On 16.12.10 5:14 , Jack Dao wrote:
>>
>>
>> HI, I have a system with dual NICs - eth0 and eth1. eth0 is live (has
>> an IP address and a cable from it's RJ45 jack into the wall). eth0 is
>> not 'live' (no IP address, and no cable).
>>
>> So I have an application that opens 2 UDP sockets, one on eth0 and the
>> other on eth1. It then sits awaiting for broadcast messages from
>> clients. When it gets one, we process it. Here's what's strange: When
>> a broadcast messages comes in, we also get the message on the socket
>> associated with eth1 (the NIC with no IP address and no cable).
>>
>> Are UDP broadcast message known to behave in this way? Could this be a
>> bug in the Linux IP stack? A but on our application?
>>
>> Any feedback appreciated.
>
>
> How do you associate a socket with an interface?

Bind to its IP address, I suppose. But his eth0 interface isn't even
configured for IP and has no IP address ... so yes, it would be
interesting to know. Perhaps they aren't UDP sockets after all?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+(E-Mail Removed)> writes:
> On Thu, 2010-12-16, Tauno Voipio wrote:
>> On 16.12.10 5:14 , Jack Dao wrote:

>>> HI, I have a system with dual NICs - eth0 and eth1. eth0 is live (has
>>> an IP address and a cable from it's RJ45 jack into the wall). eth0 is
>>> not 'live' (no IP address, and no cable).
>>>
>>> So I have an application that opens 2 UDP sockets, one on eth0 and the
>>> other on eth1. It then sits awaiting for broadcast messages from
>>> clients. When it gets one, we process it. Here's what's strange: When
>>> a broadcast messages comes in, we also get the message on the socket
>>> associated with eth1 (the NIC with no IP address and no cable).
>>>
>>> Are UDP broadcast message known to behave in this way? Could this be a
>>> bug in the Linux IP stack? A but on our application?
>>>
>>> Any feedback appreciated.
>>
>> How do you associate a socket with an interface?
>
> Bind to its IP address, I suppose. But his eth0 interface isn't even
> configured for IP and has no IP address ... so yes, it would be
> interesting to know. Perhaps they aren't UDP sockets after all?

SO_BINDTODEVICE?

--
http://www.greenend.org.uk/rjk/

On Thu, 2010-12-16, Richard Kettlewell wrote:
> Jorgen Grahn <grahn+(E-Mail Removed)> writes:
>> On Thu, 2010-12-16, Tauno Voipio wrote:
>>> On 16.12.10 5:14 , Jack Dao wrote:
>
>>>> HI, I have a system with dual NICs - eth0 and eth1. eth0 is live (has
>>>> an IP address and a cable from it's RJ45 jack into the wall). eth0 is
>>>> not 'live' (no IP address, and no cable).
>>>>
>>>> So I have an application that opens 2 UDP sockets, one on eth0 and the
>>>> other on eth1. It then sits awaiting for broadcast messages from
>>>> clients. When it gets one, we process it. Here's what's strange: When
>>>> a broadcast messages comes in, we also get the message on the socket
>>>> associated with eth1 (the NIC with no IP address and no cable).
>>>>
>>>> Are UDP broadcast message known to behave in this way? Could this be a
>>>> bug in the Linux IP stack? A but on our application?
>>>>
>>>> Any feedback appreciated.
>>>
>>> How do you associate a socket with an interface?
>>
>> Bind to its IP address, I suppose. But his eth0 interface isn't even
>> configured for IP and has no IP address ... so yes, it would be
>> interesting to know. Perhaps they aren't UDP sockets after all?
>
> SO_BINDTODEVICE?

As documented in socket(7). Ah, yes, that seems likely.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jack Dao <(E-Mail Removed)> writes:

> Yes, it is a BINDTODEVICE socket:
>
> if
> (setsockopt(servers[n].getSocketFD(), SOL_SOCKET,
> SO_BINDTODEVICE, (char
> *)&interface, sizeof (interface)) < 0) {
>
> So is this the right behavior for a socket that is bound to an
> interface which has no IP address nor cable plugged into it's RJ45
> jack, should this particular socket get UDP Broadcast message that
> eminate from the different NIC within the system?

It does sound wrong to me.

After some experimentation, I can't get an unconfigured interface to
return any packets at all, i.e. I can't reproduce the behavior you
describe.

Just a thought: can you verify that you're definitely passing a
nontrivial interface name? (strace -esetsockopt may help.) If you're
accidentally passing a null string then setsockopt() will succeed but
you won't get the device-specific bind.

My somewhat hacky test code:
http://www.chiark.greenend.org.uk/uc...t/udptest.git/

--
http://www.greenend.org.uk/rjk/

Richard Kettlewell <(E-Mail Removed)> writes:

> Just a thought: can you verify that you're definitely passing a
> nontrivial interface name? (strace -esetsockopt may help.) If you're

"strace -etrace=setsockopt", rather.

> accidentally passing a null string then setsockopt() will succeed but
> you won't get the device-specific bind.

--
http://www.greenend.org.uk/rjk/