Interface without IP address can route??

I just noticed on a 3.0.1 kernel that the system is routing packets received on an interface without an IP address. (I was trying to use the interface in a user-space wifi_station-to-wired bridge application).

[root@lf0301-demo1 lanforge]# cat /proc/sys/net/ipv4/conf/sta1/forwarding 1
[root@lf0301-demo1 lanforge]# ifconfig sta1
sta1 Link encap:Ethernet HWaddr 00:03:2D:12:16:0D
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:85248 errors:0 dropped:0 overruns:0 frame:0 TX packets:1419 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:67423391 (64.2 MiB) TX bytes:1087581 (1.0 MiB)

Seems that older stock kernels have forwarding set for interfaces without IP addresses too, so maybe it's always been this way...

Anyway, I can add some logic to my config to explicitly disable routing for interfaces w/out IP address, but it seems to me that it should automatically not route packets received on an interface that had no IP address on it..

Thanks,
Ben

It makes sense to behave this way.
IPv4 addresses are owned by the system not interfaces.
If you want to control the forwarding behavior, control ARP so it doesnt respond on the interfaces with no IP.

cheers,
jamal

Quoted 18 lines · Ben Greear

I just noticed on a 3.0.1 kernel that the system is routing packets received on an interface without an IP address. (I was trying to use the interface in a user-space wifi_station-to-wired bridge application).

[root@lf0301-demo1 lanforge]# cat /proc/sys/net/ipv4/conf/sta1/forwarding 1
[root@lf0301-demo1 lanforge]# ifconfig sta1
sta1 Link encap:Ethernet HWaddr 00:03:2D:12:16:0D
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:85248 errors:0 dropped:0 overruns:0 frame:0 TX packets:1419 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:67423391 (64.2 MiB) TX bytes:1087581 (1.0 MiB)

Seems that older stock kernels have forwarding set for interfaces without IP addresses too, so maybe it's always been this way...

Quoted 8 lines

Anyway, I can add some logic to my config to explicitly disable routing for interfaces w/out IP address, but it seems to me that it should automatically not route packets received on an interface that had no IP address on it..

Thanks,
Ben

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines · jamal

It makes sense to behave this way.
IPv4 addresses are owned by the system not interfaces.
If you want to control the forwarding behavior, control ARP so it doesnt respond on the interfaces with no IP.

I understand your argument about IPs being owned by system instead of interface, but I think it's the wrong behaviour in this case. Can you think of any case where this behaviour actually helps?

Either way, it appears I can work around this by explicitly disabling forwarding for this particular interface.

Quoted 5 lines · Ben Greear

Quoted 4 lines · jamal

It makes sense to behave this way.
IPv4 addresses are owned by the system not interfaces.
If you want to control the forwarding behavior, control ARP so it doesnt respond on the interfaces with no IP.

I agree.

Quoted 3 lines

I understand your argument about IPs being owned by system instead of interface, but I think it's the wrong behaviour in this case. Can you think of any case where this behaviour actually helps?

It's used for oddball /32 setups at server hosting farms that look like:

       /--- eth0, no ip ---- server 0.1.4.5/32, default via 0.1.2.3
router --- eth1, no ip ---- server 0.1.6.7/32, default via 0.1.2.3
       \--- eth2, no ip ---- server 0.1.8.9/32, default via 0.1.2.3
    \- eth3: 0.1.2.3/28 - to rest of internet

The general idea is to a) conserve IPs and b) not renumber servers even when they move, so you end up with random scattered /32s on the servers and the router has no sensible IP.

Quoted 2 lines

Either way, it appears I can work around this by explicitly disabling forwarding for this particular interface.

I was about to suggest exactly this :)