These days I'm in a "self learning" about a packet switching networking includes TCP, UDP, & other protocols. I have confirmed that the sender's MAC address couldn't be sent directly to receiver since the packets tend to travel via several routers (where a WAN).
But in a LAN, I assumed similar scenario, let's assume there is one router for two terminals, those are contacting a simple 'TCP chat' - designed in Java. (I'm not going to give it's code). I have designed a simple "packet sniffer" in java (by using jpcap) which extracts the MAC addresses from each "packet header" and put them in a text file as follows...
Destination MAC: ##:##:##:##:##:## /*My Terminal's MAC*/
Source MAC: ##:##:##:##:##:## /*Sender's Terminal's MAC*/
O.K..? Now... My doubt is... in the above data, I found that the router's MAC are not included...! When my terminal is the receiver, which has that packet sniffer, therefore I can directly see the sender's MAC address above..!
But my argument is... there is a router (in a LAN) in between the sender & receiver no..? Then why the above code doesn't show that router's MAC instead of showing the sender's MAC..?
But, when I executed my 'packet sniffer' when I connected to Google via a Browser, I observed the above data is viewed a as follows...
Destination MAC: ##:##:##:##:##:## /* My LAN-Router's MAC */
Source MAC: ##:##:##:##:##:## /* My Terminal's MAC */
Here I can see my LAN-Router's MAC...!
Anybody could explain why I can't see the LAN-Router's MAC when I contact via a TCP Chat with a peer in a LAN...?
Thanks in advance..!
The way in which web browsing and chat connect are (generally) different. When you connected to Google, you didn't connect directly to the IP address of Google (though you could also do that), but probably www.google.com -- which requires DNS to determine the IP address that the HTTP request should be sent to. When you use TCP chat, you're headed straight to the TCP chat on someone else's machine.