Consider the following network, with correct addressing, masks and the obvious routes.

       B   K
       |.2 |.?   10.0.0.0/24
===+===+===+================
   |.1
   R
   |.1        10.0.1.0/24
===+===+===+=======+========
       |.2 |.?     |.4
       A   J       X

Case 1: Local

A sends packet to X with correct IP source address but incorrect source MAC address

Result: frame arrives at X, which updates its ARP table, hands UDP packet upstaris in its stack, which generates a reply. Reply to A's IP address will get wrapped in the wrong ether address for the poisoned ARP cache. If the incorrect ethernet address is that of another host J, that host will receive the frame and do whatever it likes with it. If no host actually has that ether address, J can still snoop the frame, as the switches will be flooding the unknown ether detination. What happens next depends on the upper protocol, whether A notices it hasn't had a reply and starts resending, etc.

Case 2: Remote

B sends packet to X with correct IP source address but incorrect source MAC address

B sends frame to R, which might conceivably reject it. More likely it updates its ARP cache for B, and forwards the packet to X.

X receives and formulates reply, which will be directed to R because B is not local. R receives the packet, see it's for a local network, and wraps in ether with the poisoned ether address from its cache. Just like the local case, K could be the destination, or able to snoop the frame.

Notes

I've described the ordinary situation with common operating systems and routers; these are designed to minimise the manamagement required, at the cost of being open to certain kinds of problem.

You'll see that in the local and remote cases, the thing that goes wrong is that an ARP cache is updated with incorrect information. The usual reason for this is an intended ARP cache poisoning attack, and very occasionally innocent misconfiguration of something.

Many operating systems therefore allow settings to lock ARP cache entries, to prevent J and K stealing the mail of their neighbours A and B.

Consider the following network, with correct addressing, masks and the obvious routes.

       B   K
       |.2 |.?   10.0.0.0/24
===+===+===+================
   |.1
   R
   |.1        10.0.1.0/24
===+===+===+=======+========
       |.2 |.?     |.4
       A   J       X

Case 1: Local

A sends packet to X with correct IP source address but incorrect source MAC address

Result: frame arrives at switch, which updates its CAM table, then frame arrives at X, which updates its ARP table, hands UDP packet upstairs in its stack, which generates a reply. Reply to A's IP address will get wrapped in the wrong ether address for the poisoned ARP cache. The switch will normally send the reply towards the original sender, but potentially if the incorrect ethernet address is that of another host J, that host will receive the frame and do whatever it likes with it. If no host actually has that ether address, J might still be able to snoop the frame, depending on the details of the switches. What happens next depends on the upper protocol, whether A notices it hasn't had a reply and starts resending, etc.

Case 2: Remote

B sends packet to X with correct IP source address but incorrect source MAC address

B sends frame through the switch, which updates its CAM table, to R, which might conceivably reject it. More likely it updates its ARP cache for B, and forwards the packet to X.

X receives and formulates reply, which will be directed to R because B is not local. R receives the packet, see it's for a local network, and wraps in ether with the poisoned ether address from its cache. Just like the local case, depending on the details of the switch, K could be the destination, or able to snoop the frame.

Notes

I've described the ordinary situation with common operating systems, switches, and routers; these are designed to minimise the management required, at the cost of being open to certain kinds of problem.

You'll see that in the local and remote cases, the thing that goes wrong is that an ARP cache is updated with incorrect information, and switches' CAM tables. The usual reason for this kind of frame with incorrect ether source address is an intended ARP cache poisoning attack, and very occasionally innocent misconfiguration of something.

Many operating systems therefore allow settings to lock ARP cache entries, to prevent J and K stealing the mail of their neighbours A and B. Routers and switches also have facilities for preventing such things.

Consider the following network, with correct addressing, masks and the obvious routes.

       B   K
       |.2 |.?   10.0.0.0/24
===+===+===+================
   |.1
   R
   |.1        10.0.1.0/24
===+===+===+=======+========
       |.2 |.?     |.4
       A   J       X

Case 1: Local

A sends packet to X with correct IP source address but incorrect source MAC address

Result: frame arrives at X, which updates its ARP table, hands UDP packet upstaris in its stack, which generates a reply. Reply to A's IP address will get wrapped in the wrong ether address for the poisoned ARP cache. If the incorrect ethernet address is that of another host J, that host will receive the frame and do whatever it likes with it. If no host actually has that ether address, J can still snoop the frame, as the switches will be flooding the unknown ether detination. What happens next depends on the upper protocol, whether A notices it hasn't had a reply and starts resending, etc.

Case 2: Remote

B sends packet to X with correct IP source address but incorrect source MAC address

B sends frame to R, which might conceivably reject it. More likely it updates its ARP cache for B, and forwards the packet to X.

X receives and formulates reply, which will be directed to R because B is not local. R receives the packet, see it's for a local network, and wraps in ether with the poisoned ether address from its cache. Just like the local case, K could be the destination, or able to snoop the frame.

Consider the following network, with correct addressing, masks and the obvious routes.

       B   K
       |.2 |.?   10.0.0.0/24
===+===+===+================
   |.1
   R
   |.1        10.0.1.0/24
===+===+===+=======+========
       |.2 |.?     |.4
       A   J       X

Case 1: Local

A sends packet to X with correct IP source address but incorrect source MAC address

Result: frame arrives at X, which updates its ARP table, hands UDP packet upstaris in its stack, which generates a reply. Reply to A's IP address will get wrapped in the wrong ether address for the poisoned ARP cache. If the incorrect ethernet address is that of another host J, that host will receive the frame and do whatever it likes with it. If no host actually has that ether address, J can still snoop the frame, as the switches will be flooding the unknown ether detination. What happens next depends on the upper protocol, whether A notices it hasn't had a reply and starts resending, etc.

Case 2: Remote

B sends packet to X with correct IP source address but incorrect source MAC address

B sends frame to R, which might conceivably reject it. More likely it updates its ARP cache for B, and forwards the packet to X.

X receives and formulates reply, which will be directed to R because B is not local. R receives the packet, see it's for a local network, and wraps in ether with the poisoned ether address from its cache. Just like the local case, K could be the destination, or able to snoop the frame.

Notes

I've described the ordinary situation with common operating systems and routers; these are designed to minimise the manamagement required, at the cost of being open to certain kinds of problem.

You'll see that in the local and remote cases, the thing that goes wrong is that an ARP cache is updated with incorrect information. The usual reason for this is an intended ARP cache poisoning attack, and very occasionally innocent misconfiguration of something.

Many operating systems therefore allow settings to lock ARP cache entries, to prevent J and K stealing the mail of their neighbours A and B.