Why can't the server get the client MAC address, like the client IP?_问答_开发者

From what I know, all the MAC addresses that the packet gone through are in the packet. This is because that each packet that goes in a certain path, should also be returned in similar path. So, if the router of the server know about the mac address of the client (all of them), why the server page (like aspx) cannot have this information?

Please, give an explanation. (don't just tell me that I'm wrong).

If I understand it correctly, the client sends a packet that c开发者_JS百科ontains it's MAC address. when to packet go through a proxy (like the client router), the proxy's address is added to the packet too. and so on.

Here is a snippet from Wikipedia about the TCP/IP data line layer:

http://en.wikipedia.org/wiki/TCP/IP_model#Data_Link_Layer

The Data Link Layer is used to move packets between the Internet Layer interfaces of two different hosts on the same link. The processes of transmitting and receiving packets on a given link can be controlled both in the software device driver for the network card, as well as on firmware or specialized chipsets. These will perform data link functions such as adding a packet header to prepare it for transmission, then actually transmit the frame over a physical medium. The TCP/IP model includes specifications of translating the network addressing methods used in the Internet Protocol to data link addressing, such as Media Access Control (MAC), however all other aspects below that level are implicitly assumed to exist in the Link Layer, but are not explicitly defined.

Actually, the MAC-address stored in the packet is changed on every hop of a packet's journey.

MAC is shorthand for Media Access Control, with media refering to the local communication media. While source and destination IP-Addresses remain the same throughout the journey (and are used for long-distance routing decisions), the source and destination MAC-Addresses just indicate the next hop.

Because of this, the MAC-Address stored in packets received by your server should be the MAC address of your point of presence-router, or of the equipment of your provider.

You might want to have a look at the OSI Layer model and encapsulation.

You have the relationship between the IP stack and the physical stack reversed. The MAC address is in the part that wraps the IP information, not the other way around. So when I send something from my computer, say, to yours, the physical segment in my LAN (Ethernet in this case) wraps around the IP stuff and includes my MAC. The router then extracts the IP information and passes that onward and upward (in this case again by Ethernet) to my DSL modem using its own MAC in the process. The DSL modem unwraps the IP stuff and sends that up the phone line using whatever protocol it uses (don't know and don't care at that point) out to ... well, you get the idea. Each physical link hop wraps and unwraps the IP information using whatever extra information the underlying physical layer involved attaches for local transmission.

In IPv6, one might actually get the computer's MAC address from the IPv6 address, if encoded into the 64 bits of the host address.

See also How to avoid exposing my MAC address when using IPv6? on Super User.

There is no "router of the server". Packets may reach the server from many routers.

There is no "router of the client". Packets may be sent from the client to many routers.

The only devices which can see a MAC address are those on the same LAN - possibly only those on the same cable segment.

BTW, the server cannot get the client IP address, either, if the client is on the other side of a proxy server.

It's source & destination IP address which remain. The idea of inter-network is basically based on hop-to-hop delivery. Intermediate routers/host understands only MAC addresses. To my knowledge routing tables should understand machine address.

If MAC addresses could remain throughout the journey of a packet; which means there was no need of Internet Protocol addresses to be invented. And all of the internet would have used only MAC addresses :-)

You can achieve what you want only if both the server & client reside on the same local network (both hosts are connected by some L1 media).

Having said that, your application looks something like a Web Server, which tells me that it need not be on the same network.

Still if you want the MAC address of the source host at the receiving host; think to sent it as a payload?

Addition:

Networks need not be of the same type around the world (viz. Ethernet, Frame relay etc). Network layer provides us with the flexibility of routing without distinction between underlying layers(Data Link Layer) or I should say underlying L1 technology. In short, IP will give us the inter-network and Data Link Layer(where MAC addresses come into picture) will take care of communication at micro level (i.e. local network). This is a fair reason why Mac and IP addresses co-exist! :-)

You can't - unless the client is local to your server. Provided it is, you can try arp-pinging it and getting the client's mac address that way.

You're thinking in terms of direct connection between the server's LAN and the client's LAN, and that's just not the way the internet works. There may be any number of hops between the two LANs -- and, by the way, there is no constraint that either LAN use anything like a MAC, so "MAC addresses" are not placed in IP packets. "A MAC" makes sense only within a LAN (actulaly, only one whose lowest layers do use something like MACs;-), and are discovered/announced with the ARP and RARP protocols (which do not get routed;-).

The simple difference is: IP addresses are end to end adresses (in an IP packet of course), whereas MAC adresses are only used hop by hop. Additionally the underlying MAC protocol could change on every hop, without knowledge of the client, therefore the client may not even understand all the adresses along the way of its IP packet.

Before understanding that why the server cannot access the MAC address of its client, lets understand how a data packet traverse in a network.

Case 1 :

The destination IP address will be known to the network application or obtained from a DNS server in case the application knows a domain name only. Then the host will compare the destination IP address with its own IP address and subnet mask. If the destination host is within the source host's network, the source host will send an ARP request onto the wire asking "who has that IP address?" and the destination host will reply with its MAC address.

Case 2 : (which is generally the case over the Internet)

If the destination host is not within the source host's network, lets say when we are browsing Google.com, the DNS will resolve the Name to IP. the source host will send an ARP request asking "who has the IP address of my default gateway?". In this case since it is out of our network, we will send ARP request to our Default Gateway(A default gateway is the node in a computer network using the internet protocol suite that serves as the forwarding host (router) to other networks), and DG replies with its MAC. You send the packet with Destination IP of Google and Destination MAC of our DG. When the DG recieves this Frame with its own destination MAC and some other destination IP address in the IP Header, it knows that the packet is not destined to itself, but only traversing. Then the ip lookup for google, followed by ARP for next hop etc continues..

So you see, the data link layer that does physical addressing never knew the MAC address of the destination, it only knew the MAC address of next HOP(router). The MAC address of the next router is obtained through ARP request. So how does the receiver know MAC address of its sender. Well it never knew nor it can because every time the packet was received by a router, it added its own MAC address in the source MAC address field or rather say it replaced it with its own. Hence the server will never be able to know MAC address of its receiver as it never was there in the packet. Its just the IP address that remains.