Re: How to indenfy the real physical network interface?

[Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

On Mon, 2011-11-07 at 05:59 -0800, santosh wrote:
> Hi,
> 
> I am posting this question to "netdev" mailing list because I could
> not find "linux-net" mailing list as suggested at
> http://kernelnewbies.org/ML .

I'm not aware of the networking "user" mailing list, this is the
development mailing list.

> 
> I have a wireless device running on Linux 2.6.15. (Can't upgrade to
> latest at this time).
> 
> It has 3 interfaces.
>  ath0 - Wireless interface.
>  eth0 - Ethernet interface.
>  br0 - Bridge interface joining ath0 and eth0.
> 
> I have a user space socket program that listens to the broadcast
> messages and responds.
> My socket is opened as sock = socket(PF_INET, SOCK_DGRAM, 0).
> 
> I need this socket program to listen for the packet coming from
> Ethernet interface only.
> Or, this socket program should be able to figure out the actual
> interface the packet come from.
> 
> I tried below methods but both doesn't help me because kernel is
> giving bridge as interface and not giving the real interface to socket
> program.
> 
> 1. //setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, "br0", 3)
>  setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, "eth0", 4)
> 
> 2. setsockopt(sock, SOL_IP, IP_PKTINFO, (char *) &on, sizeof on)
>  // Use recvmsg instead of recvfrom and read the interface index.
>  // If interface is not Ethernet do not respond.
> 
> Can you please let me know if there is a way to identify the actual
> interface in a UDP socket program when traffic is being controlled by
> a Bridge?

Not in the kernel you're using, that's a very old kernel.  I made some
changes in the 2.6.22 kernel (also ancient) that would allow the "real"
device to be returned instead of a bridge or bond device.  I think
you're SOL if you want this behavior, but can't upgrade to a much more
sane kernel.  The issue is the "real" device is resolved to the bridge
device in the socket code, since that is what the routing table
eventually sends stuff out on (before resolving to the "real" device in
the networking core layer).

Upgrade to a much more recent kernel to at least test.  Otherwise
there's nothing anyone here can do.

Cheers,
-PJ

-- 
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
LAN Access Division, Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4394 bytes --]