1

In an embedded system using linux 5.3.18 it is required to ignore ICMP broadcasts. This device IP set to 192.168.0.34/25, so the broadcast will be 192.168.0.127. The flag controlling this behaviour icmp_echo_ignore_broadcasts is correclty set to 1

When an ICMP echo request with source IP 192.168.0.127 is sent, I would expect this request to be ignored since a response would be a broadcast, but the response is present and the dst MAC is now ff:ff:ff:ff:ff:ff

If the mask is set to /24 this works as intended. Is my undestanding of calculated broadcast incorrect? Why was the dst MAC address changed?

Improve this question
3
  • 1
    You set the source IP to the broadcast address!?
    – Michael Hampton
    Nov 10, 2020 at 20:16
  • Not sure if I undestand you, I've modified the question. The device has IP 192.168.0.34/25. The source address of the ICMP pkg it is the broadcast address.
    – GurstTavo
    Nov 10, 2020 at 20:20
  • 1
    Broadcast and multicast addresses are not allowed to be source addresses. You broke that rule, so the reply will be back to the broadcast address as the reply destination (original source) address, both at layer-2 (MAC) and layer-3 (IP). You host implementations are flawed to allow and accept a source broadcast address.
    – Ron Maupin
    Nov 10, 2020 at 23:07

1 Answer 1

Reset to default
3

ICMP echoes don't have a source address as a broadcast. The source is the unicast address of the source. The destination will be a the broadcast address.

Improve this answer
4
  • Then the test method is incorrect? If so, then the response to the ip dst 192.168.0.127 is not a broadcast?
    – GurstTavo
    Nov 10, 2020 at 20:29
  • No the response destination is the unicast source
    – Ron Trunk
    Nov 10, 2020 at 20:37
  • any clue why the MAC address was changed to ff:ff:ff:ff:ff:ff?
    – GurstTavo
    Nov 10, 2020 at 20:40
  • 2
    Because you set the source to the broadcast address. It's an invalid packet that you would never see on your network.
    – Ron Trunk
    Nov 10, 2020 at 20:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .