-3

How does changing a network interface's MAC address (ifconfig eth2 hw ether BB:BB:BB:BB:BB:BB) affect a NIC that isn't in promiscuous mode?

When I use ifconfig to change my network card's MAC, it is reverted to the original MAC after a reboot. As far as I understand, it means that the network card has its original MAC saved in its own nonvolatile memory and Linux reads this original MAC every time it boots. It must mean that ifconfig does not change the MAC's value saved in NIC's own nonvolatile memory. This value is left untouched.

Nevertheless, when I change the MAC with ifconfig, Linux starts sending Ethernet frames with this new MAC as source-MAC.

From what I have learnt, a NIC that is not in so called "promiscuous mode" rejects all Ethernet frames whose destination MAC addresses differ from the NIC's MAC address (unless it's broadcast or multicast). It means that Linux will not even see those frames. They will be dropped before reaching the CPU. I suppose the NIC does this job by checking the Ethernet frame's destination MAC address against the NIC's MAC address saved in NIC's own nonvolatile memory.

Now there comes an issue that I don't understand. Since NIC uses its internally saved original MAC to decide whether to drop a frame before passing it to the CPU, and Linux may use a totally different MAC as source MAC for outgoing frames, then how does a response to such frames reach Linux?

What do I misunderstand in this topic?

I will present an example to better describe what I mean.

NIC has AA:AA:AA:AA:AA:AA stored in its own internal nonvolatile memory as its original MAC. It is not in promiscuous mode, so it prevents all frames not containing AA:AA:AA:AA:AA:AA as the destination MAC from reaching the CPU (and Linux). Now someone types: ifconfig eth2 hw ether BB:BB:BB:BB:BB:BB. From now on, outgoing frames sent by Linux from this interface will have BB:BB:BB:BB:BB:BB as source MAC. Eventually another host will reply to this frame by sending a frame with BB:BB:BB:BB:BB:BB as destination MAC. Such a frame will arrive to the first host's NIC. What will the NIC do now? It will compare BB:BB:BB:BB:BB:BB with AA:AA:AA:AA:AA:AA (stored internally in NIC's ROM) and decide not to pass it to the CPU?!? So the frame will never reach Linux?

Where's the catch?

Piotr S
  • 95
  • 1
  • 1
  • 4

1 Answers1

0

The MAC address in modern network interfaces is a volatile value held in a configuration register of the chip. That's the only value that is used in chip's operation outside of initialization. This value is initialized on start up from non-volatile memory - either by the chip hardware itself, or by the driver, depending on the particular chip's design.

The non-volatile value is not used for anything but the initialization. It is certainly not used to filter out the incoming packets - the nonvolatile memory is much too slow for that. During network interface's operation, the nonvolatile memory is idle and is not used.

The promiscuity of the NIC had nothing to do with your question. As soon as you assign a new MAC, it takes effect, no matter what the nonvolatile memory contents might be, and no matter whether the interface is promiscuous or not.

Finally, the non-volatile memory in a NIC interface is optional. On many mobile systems (say laptops) there's no nonvolatile memory dedicated to the NIC. The MAC address of the NIC is held in the nonvolatile memory that stores other system-specific nonvolatile configuration data. This saves power and money.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • Thank you for the answer. So it means that the NIC hardware contains at least two values for the MAC - one in non-volatile and one in volatile memory. – Piotr S Aug 01 '14 at 20:38
  • @PiotrS Yes, with the understanding that the non-volatile value might not exist in anything related to the NIC hardware. It may be in general-purpose nonvolatile storage. – Kuba hasn't forgotten Monica Aug 03 '14 at 02:46
  • "It may be in general-purpose nonvolatile storage". But then, as far as I understand, the volatile value will have to be initialized by the driver, not by the NIC hardware, as the NIC has no knowledge of the nonvolatile value. So it means the NIC will not work correctly without its volatile value being first initialized by the driver. – Piotr S Aug 03 '14 at 08:47
  • @PiotrS Sure. That's why the volatile value is often set during system startup, by the system firmware (sometimes called BIOS). I forgot to mention that detail. The system firmware often acts as a driver to perform network boot. – Kuba hasn't forgotten Monica Aug 03 '14 at 15:47