Quote:
Originally Posted by Mediaguy
Moe, they're right of course - since if you read the WHOLE page is describing an experiment within a "home network" demonstrating how to capture your packets within a LAN:
"In my home network, I have a computer named "genisis" with an IP address of 10.0.0.1; it is connected using an Ethernet topology to a computer named "biko" whose IP address is 10.0.0.2."
Note the IP addresses. Check his IP Packet. The entry for IP is "biko" from "ginisis" - or local subnet, which means of course you'll see the last sending device's MAC address. You'll see this whether you're reading the last hop from a router or a compute-to-computer transimission in your LAN.
So they're right, because they're talking about a local network.
|
"When your request shows up at the router that connects to The TCP/IP Guide, it can see the
http://www.tcpipguide.com server's IP address, but that isn't helpful: it needs to send to server's MAC address.
The identical issue exists even with communication between devices on a LAN."
That last sentence tells us that that what I referred to applies to a WAN AND a LAN.
Quote:
Originally Posted by Mediaguy
YOU are not. You think this is about WAN-side transmission of TCP/IP packets but it is STILL about LANs and subnets.
Did you think I was going to read just the last paragraph out of context and think that everything else available on the matter was wrong?
|
That was meant to illustrate the anatomy of a TCP packet.
Quote:
Originally Posted by Mediaguy
There's too much thinking of that sort here. You should really yank back on the throttle a little before you start calling people morons and imbeciles. The more of that you do, especially when you're wrong, the more you become those.
oh and ps.: sniffing backwards you will not get the same route, and even if you did your device routing tables contain more than one send destination; these nodes don't remember where they sent what packet or when they sent them; that is simply too much useless data to process.
|
Wrong. Think traceroute, and think packet sniffer, at every hop . . .
If the connection from the originating device were terminated, that would be another matter.
As I said, doing that with software alone (as in automatically, minus a human) would not be infallible every time . . . but with a human, UNLESS one of the devices at one end of one of the hops were VERY secure (and I mean secure as in OpenBSD + firewall hardware + some competent sysadmins + some specialized intrusion detection software) it would be trivial for many folks to do . . . oh, and before you accuse me of claiming I am into cracking, I will repeat: I am not into it . . . not interested . . . I have obtained proper reference material on networking because I am interested in Web Applications . . . and that is all.
What I can't believe is, coming across people who make their living from doing business online, and who not only do not know this stuff, but do not even have access to proper reference material. That amazes me.