Please don't criticise the solution. It's not my design and yes, it sucks.
On a computer running Linux, and using C, we need to verify that a TCP connection made to a process is from the same machine. Doing it by IP address is problematic since the OS is generating two IP addresses and the process only knows one. Anyway, verifying by IP address is a bit poor.
We want to do the verification by comparing the "remote" MAC address to the local MAC address. We already get the local MAC address. All I need to know is how to get the "remote" MAC address. It's in the packet that gets sent when forming the connection (and in all subsequent ones too). How do we drag it out of the ethernet layer?
Before anyone says this again, I KNOW you cannot get the MAC address of the remote host if it's not on the same subnet/LAN. That's fine. Presumably we'll get something like 00:00:00:00:00:00 and since that is different to the local MAC address it will be different - just what we want.
--
So, to summarise, we have a TCP connection socket fd, we've received a data packet, how do we then find the MAC address of the remote host, the MAC address that was in the packet's header?
If I understand correctly, you are not trying to tell remote machines apart, but to use the idea that the source and destination MAC would match on traffic sent from a machine to itself in order to allow only local traffic.
This seems rather roundabout, and has been pointed out, insecure.
A somewhat better idea might be to have the TCP client listen only on the loopback interface (127.0.0.1) and not on INADDR_ANY. Or go a step further and use a unix-domain socket instead of a TCP one (a common method used by X servers today to prevent the possibility of remote connections)