2
My two hosts reside on the same Ethernet segment. Host A is 10.1.0.1/16, host B is 10.1.0.2/16. A sends directed UDP broadcasts to 10.1.255.255 and a UDP listening socket bound to INADDR_ANY on B receives them.
After I'm changing IP configuration on A to 10.0.0.1/16 so that it belongs to a different IP subnet and starts broadcasting to 10.0.255.255, that same socket on B still receives this broadcast.
If I restart the listening application on B, these broadcasts to a "wrong" subnet are not received by the socket any more.
Question: why the networking stack of B does not drop the packet, which is neither a unicast to B nor a broadcast to subnet of B, until socket shutdown?
I know that RFC1122 says:
Hosts SHOULD use the Limited Broadcast address to broadcast to a connected network.
I understand that the application on A sending directed broadcasts with the intention to broadcast to own subnet does not follow the "should" clause. But my question is why B does not drop them as long as UDP socket is alive.
I observed this behavior on Linux kernels 4.4 and 3.13.
Konstantin Shemyak
Posted 2017-08-13T09:56:56.693
Reputation: 243
2When you say "B receives this broadcast", what program is actually showing that – packet capture (tcpdump) or a regular UDP socket? – user1686 – 2017-08-13T11:10:05.097
@grawity UDP socket. (Naturally, tcpdump as well, also when the interface is not in promiscuous mode.) – Konstantin Shemyak – 2017-08-13T13:06:33.697
Just because host B sees the traffic, which is normal, doesn't mean that it acts on it. Depending on your monitoring method, you may be misinterpreting your data. If you are using a network sniffing tool the Ethernet adapter is probably in promiscuous mode, so ofcourse it is going to see all traffic on the network rather it is addressed to it or not. – Appleoddity – 2017-08-13T13:24:55.080
It also matters if these devices are connected via a switch or hub. – Appleoddity – 2017-08-13T13:25:52.683
@Appleoddity in the comment above I have explicitly mentioned reception of the packet by the UDP socket (and also using not promiscuous mode when running sniffer). – Konstantin Shemyak – 2017-08-13T13:28:21.843
2@Appleoddity: At Ethernet layer it's perfectly normal regardless (since all broadcast types share the same MAC address); I suppose the OP is asking why it's not dropped once it reaches IP layer. – user1686 – 2017-08-13T13:28:44.673
@user3608247 I don't see either thing you mentioned just now in your question, but that is neither here nor there I guess. Do you have ip forwarding enabled on your host b? This would cause the ip stack to respond to any packet also I would think. – Appleoddity – 2017-08-13T13:42:05.223
Wait, sorry to turn this in to a conversation, but you ARE using a sniffer than to determine if the host is receiving the packet? Of course the sniffer sees it. Just like @grawity mentioned they all use the same broadcast MAC address so the network card will receive the packet and it will show up in a sniffer but it will not pass layer 3 of the OSI stack. – Appleoddity – 2017-08-13T13:46:07.000
@grawity I have edited the question. The unexpected reception of broadcasts to a "wrong" subnet continues only until listening UDP socket shutdown. – Konstantin Shemyak – 2017-08-13T13:50:23.520
Looks like the same problem has been reported 6 months ago on serverfault: https://serverfault.com/questions/830364/application-receiving-boradcast-from-different-subnet
– Konstantin Shemyak – 2017-08-14T18:43:21.907