# Interface alias does not receive broadcast traffic

## l_bratch

When setting up an alias for eth0, the interface works as expected for normal traffic, but does not receive broadcast traffic.

Host 1's setup:

```
# ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:17:31:f5:9d:63  

          inet addr:192.168.0.107  Bcast:192.168.0.255  Mask:255.255.255.0

          inet6 addr: fe80::217:31ff:fef5:9d63/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:22749 errors:0 dropped:0 overruns:0 frame:0

          TX packets:18614 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:4245622 (4.0 MiB)  TX bytes:2217688 (2.1 MiB)

          Interrupt:16 

# ifconfig eth0:0

eth0:0    Link encap:Ethernet  HWaddr 00:17:31:f5:9d:63  

          inet addr:192.168.0.150  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Interrupt:16 
```

Pinging host 1's normal interface from host 2 works as expected:

```
$ ping 192.168.0.107

PING 192.168.0.107 (192.168.0.107) 56(84) bytes of data.

64 bytes from 192.168.0.107: icmp_req=1 ttl=64 time=0.274 ms

64 bytes from 192.168.0.107: icmp_req=2 ttl=64 time=0.276 ms

^C

--- 192.168.0.107 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.274/0.275/0.276/0.001 ms
```

Pinging host 1's alias interface from host 2 works as expected:

```
$ ping 192.168.0.150

PING 192.168.0.150 (192.168.0.150) 56(84) bytes of data.

64 bytes from 192.168.0.150: icmp_req=1 ttl=64 time=0.281 ms

64 bytes from 192.168.0.150: icmp_req=2 ttl=64 time=0.275 ms

^C

--- 192.168.0.150 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1000ms

rtt min/avg/max/mdev = 0.275/0.278/0.281/0.003 ms
```

Broadcast pinging from host 2 only gets a reply from host 1's real interface (as well as some other uninteresting devices on the network):

```
$ ping -b 192.168.0.255

WARNING: pinging broadcast address

PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data.

64 bytes from 192.168.0.107: icmp_req=1 ttl=64 time=0.285 ms

64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.289 ms (DUP!)

64 bytes from 192.168.0.35: icmp_req=1 ttl=255 time=0.982 ms (DUP!)

64 bytes from 192.168.0.107: icmp_req=2 ttl=64 time=0.274 ms

64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.278 ms (DUP!)

64 bytes from 192.168.0.35: icmp_req=2 ttl=255 time=0.994 ms (DUP!)

^C

--- 192.168.0.255 ping statistics ---

2 packets transmitted, 2 received, +4 duplicates, 0% packet loss, time 1000ms

rtt min/avg/max/mdev = 0.274/0.517/0.994/0.333 ms
```

I have confirmed by listening on both interfaces using netcat, and broadcasting using netcat, and again only the real interface receives data.

Is this by design, or is it possible to get interface aliases to receive broadcast traffic?

----------

## Hu

What were you expecting to happen?  Do you want eth0 and eth0:0 to respond, so that each ping gets two pongs?

Why are you using interface aliases?  You can assign multiple addresses to the main interface if you use sys-apps/iproute2.

----------

## l_bratch

 *Hu wrote:*   

> What were you expecting to happen?  Do you want eth0 and eth0:0 to respond, so that each ping gets two pongs?

 Correct.  The goal of this is to have two services that are broadcast discoverable - one on each address, but using the same port number.

 *Quote:*   

> Why are you using interface aliases?  You can assign multiple addresses to the main interface if you use sys-apps/iproute2.

 Perhaps I am using the wrong thing, I'll investigate iproute2!

----------

## Hu

 *l_bratch wrote:*   

> The goal of this is to have two services that are broadcast discoverable - one on each address, but using the same port number.

 Have you checked that this does not work with the changes you have done so far?  You tested with ICMP, but it sounds like your production design will use UDP.  They may behave differently, so I suggest setting up a listener on each of the two addresses and generating your UDP broadcast to see if both can receive it.

----------

