Do you want Gonzo to post your real name?

[Toby]

- Page 7 -

I can't decide whether or not it's time for the beating a dead horse smiley.

[gonzo]

[StaciEroticy508]

oh, and btw....you all crack me up! Thanks!

[Hammer]

Originally Posted by rhetorical

That's cause your not Canadian. I kind find paint drying more amusing but it doesn't last as long.

ummm... your sarcasm alarm should have been screaming at you. And I'm not even a big hockey fan.

[Sexyteaser]

Hammer - Now I know you keep bumping this so everyone can see my apology!

[sarettah]

lol. 7 pages.. damn

Weather in Aspen is almost perfect

[softball]

Originally Posted by Hammer

ummm... your sarcasm alarm should have been screaming at you. And I'm not even a big hockey fan.

Shit I forgot to change the batteries. Now I gotta go around the house and put new batteries in my smoke detectors, my co detectors, my bullshit detectors, and my asshole detectors. No big deal but do you know how much those fucking nicklemetalhydridemthaneplutoniumleadacid batteries for those fucking sarcasm alarms cost?

[moetheman]

Originally Posted by Mediaguy

Hey Moe

You're wrong. Got the texts, read the technical, and talked to a microsoft programmer.... personal network card MAC addresses aren't contained within the ethernet envelope, the TCP/IP packet or anywhere outside my LAN.

Stop posting to the contrary. You're wrong.

Page 280. Your "microsoft programmer" is obviously fictional.

Originally Posted by Mediaguy

Quite simply you are incorrect, check with your so-called tech community, it's not there that info, you're wrong wrong wrong....TCP/IP packets carry the MAC address of the last device that forwarded them, that's it, if they had anything compared to an ARP table for some reason, all our broadband and DSL connections would be as fast as dial-up.

No MAC Address. C'est toot. you may have mis-read whatever fifty dollar text book you got, that's all and understandable... you even had me doubting what I was reading... but nope.

Page 280. Buy it, read it, . . . hahaha . . . how pathetic of you.

[moetheman]

Originally Posted by DannyCox

I do find this amusing. I just asked the question of MAC Addresses in packets, and never got an answer. I then spent about 30 minutes checking sites (some of which I linked to in my previous post, because I believe a person should backup what he is stating) and found, conclusively, that MAC Addresses do not make up any part of a TCP/IP Packet. moetheman then has to resort to using profanity in his answer, and still has not shown a thing to back up his claim, other than an a reference to a page in some obscure networking book.

Moe, you can use all the profanity that you like, but I will state that you "are wrong". I also know that everyone else here thinks you are wrong as you refuse to support any claim you make with documentation. I backed up what I said, now please do the same. And I think we need more than the single reference that you eluded to. If what you state is accurate, you should easily be able to find backup across the 'net.

BTW, just as an aside......who is "moetheman" anyway?? Am I just having a discussion with yet another surfer/wannabe??

Page 280. If I were on a tech board (not that there would be a need to) I would scan the page and temporarily upload it to a free server someplace . . . give it up, you are not going to get me to do that here, if you want quality info GET A TEXTBOOK . . .

[moetheman]

Originally Posted by Mediaguy

You're wrong. Got the texts

You got the text?

RIGHT.

[DannyCox]

I guess your just going to stand behind your supposed single source of "proof" to back up your claim...the single source that you refuse to share. If what you say is so obviously true, you should easily be able to find reference to it all over the Internet and be able to post links to valid sites, like I did to refute your claims.

Yelling out "Page 280...Page 280...Page 280" on every one of your posts is just making you look foolish. As Ben Franklin said, "The definition of insanity is doing the same thing over and over and expecting different results."

It is time for you to give this up and concede you are wrong.

[softball]

john 3:16

[DannyCox]

I prefer Austin 3:16

[softball]

Originally Posted by DannyCox

I prefer Austin 3:16

I bet you do. I miss those blood soaked nights of hard core wrestling and fans with weapons. Sometimes living in the west sucks the big one. I still got a couple of t shirts that I wear. Those were great nights. Especially the guy that fell from the balcony and knocked himself unconscious in that theatre downtown.

[Mediaguy]

Originally Posted by moetheman

You got the text?

RIGHT.

You are correct. I did not acquire your particular bible, I referred to texts, in the plural sense, which contained much information and instructional perhaps not included in your sacred text which seems to be the only source for the occult, secret knowledge which all other sources refute.

[moetheman]

fla

Originally Posted by DannyCox

I guess your just going to stand behind your supposed single source of "proof" to back up your claim...the single source that you refuse to share. If what you say is so obviously true, you should easily be able to find reference to it all over the Internet and be able to post links to valid sites, like I did to refute your claims.

Yelling out "Page 280...Page 280...Page 280" on every one of your posts is just making you look foolish. As Ben Franklin said, "The definition of insanity is doing the same thing over and over and expecting different results."

It is time for you to give this up and concede you are wrong.

Your logic is flawed. The fact that you cannot find something online for free means nothing as to whether or not it exists, or whether it is accurate.

I shared the source, however, if you are too cheap to buy a textbook, that's YOUR problem.

Quit trying to get me to violate copyright and post a scan of the page. Not doing it.

You all look pretty ridiculous, clamoring for an answer and refusing to buy a textbook, after someone has posted a link to it on Amazon, and given you the page number to where the information is located.

Go on, keep making asses of yourselves . . . I posted a link to the info and a page number reference. QUIT BEGGING FOR A FREEBIE ALREADY

[moetheman]

ho

Originally Posted by Mediaguy

You are correct. I did not acquire your particular bible, I referred to texts, in the plural sense, which contained much information and instructional perhaps not included in your sacred text which seems to be the only source for the occult, secret knowledge which all other sources refute.

Have you any idea how ridiculous your little charade is?

"sacred text" "occult" . . . sheer childish ignorance on your behalf. I could tell you were a clown the second I saw a picture of you.

"REFUTE"? Look up the meaning of that word, I don't think that means what you think it means . . .

You two are going to look as stupid as you deserve to when someone who reads this thread gets that book (or quotes another textbook on networking) and posts the info from the page I have quoted . . .

Do you two clowns REALLY FUCKING THINK that I would post a reference to a textbook AND a page number IF I WERE NOT 100% certain that I am right?

HAHAHAHAHA

I am a programmer, you twits, my life REVOLVES around accurate information . . . not around little cheating and stealing games, like SOME people around here . . .

HAHAHAHAHAHAHA

You two are fun . . . c'mon, keep entertaining me . . .

[gonzo]

Originally Posted by DannyCox

I guess your just going to stand behind your supposed single source of "proof" to back up your claim...the single source that you refuse to share. If what you say is so obviously true, you should easily be able to find reference to it all over the Internet and be able to post links to valid sites, like I did to refute your claims.

Yelling out "Page 280...Page 280...Page 280" on every one of your posts is just making you look foolish. As Ben Franklin said, "The definition of insanity is doing the same thing over and over and expecting different results."

It is time for you to give this up and concede you are wrong.

Here is the cut and past from page 280... drop your email in here if you want the pdf scan of the page.

I dont have FTP access currently to the Oprano server so I cant send it up.

--------------------------280-------------------------------------------

The most important distinction between these types of addresses is the distinction between
layers two and three themselves: layer two deals with directly-connected devices (on the
same network) while layer three deals with

indirectly-connected devices (as well as
directly-connected). Say, for example, you want to connect to the Web server at http://
www.tcpipguide.com. This is a web site that runs on a server that has an Ethernet card in it
for connecting it to its Internet service provider site. However, even if you know its MAC
address, you cannot use it to talk directly to this server using the Ethernet card in your
home PC, because the devices are on different networks.in fact, they may be on different
continents!
Instead, you communicate at layer three, using the Internet Protocol and higher layer
protocols such as TCP and HTTP. Your request is routed from your home machine, through
a sequence of routers, to the server at The TCP/IP Guide, and the response is routed back
to you. The communication is, logically, at layers three and above; you send the request not
to the MAC address of the server.s network card, but rather to the server.s IP address.
However, while we can virtually connect devices at layer three, these connections are
really conceptual only. When you send a request using IP, it is sent one hop at a time, from
one physical network to the next. At each of these hops, an actual transmission occurs at
the physical and data link layers. When your request is sent to your local router at layer
three, the actual request is encapsulated in a frame using whatever method you physically
connect to the router, and passed to it using the router's data link layer address. The same
happens for each subsequent step, until finally, the router nearest the destination sends to
the destination using its data link (MAC) address. This is illustrated in Figure 44.

Converting Layer Three Addresses to Layer Two: Address Resolution

The basic problem is that IP addresses are

too high level for the physical hardware on
networks to deal with; they don't understand what they are. 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. Even if the
Web server is sitting on the same desk as the client, the communication is logically at the IP
layer, but must also be accomplished at the data link layer. This means we need a way of
translating between the addresses at these two layers. This process is called address
resolution.

Key Concept:

Address resolution is required because internetworked devices
communicate logically using layer three addresses, but the actual transmissions

between devices take place using layer two (hardware) addresses.

The TCP/IP Guide - Version 3.0 (Contents) �� 280
© 2001-2005 Charles M. Kozierok. All Rights Reserved.

[Hammer]

Now how hard was that instead of telling everyone to go buy a book to prove something?

[Mediaguy]

"The same happens for each subsequent step, until finally, the router nearest the destination sends to the destination using its data link (MAC) address."

[gonzo]

Originally Posted by Hammer

Now how hard was that instead of telling everyone to go buy a book to prove something?

All this big MAC talk makes me want to go get a cookie.

[DannyCox]

Thanks for posting that Gonzo, it just backs up what we have been saying all along. Your machine's MAC Address is not sent in the packet and is just used on the LAN for address resolution of the final destination. But what is being discussed only holds true on a Network. For example, if you are on a PC with just a dial-up connection, the MAC Address of your machine doesn't even come into it.

I don't see how moe could get MAC Address transmission in a TCP/IP Packet from any of that text. It is only discussing using the MAC upon receiving a packet.

[EmporerEJ]

Originally Posted by Hammer

For the record, I apologized to Shelleehale for calling her an idiot, I did not take anything back. Just wanted to make that clear.

We now resume the Shelleehale vs. 2MuchMark bout without further interruption from me.

Sig whore....


Much better sig-------vvvvvv

[moetheman]

Originally Posted by DannyCox

Your machine's MAC Address is not sent in the packet and is just used on the LAN for address resolution of the final destination.

Are you retarded man? Seriously. The following refers to the WAN:

"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."

Originally Posted by DannyCox

But what is being discussed only holds true on a Network. For example, if you are on a PC with just a dial-up connection, the MAC Address of your machine doesn't even come into it.

"The identical issue exists even with communication between devices on a LAN."

Originally Posted by DannyCox

I don't see how moe could get MAC Address transmission in a TCP/IP Packet from any of that text. It is only discussing using the MAC upon receiving a packet.

Listen, you can't posssibly be THAT dense. READ.

"However, while we can virtually connect devices at layer three, these connections are
really conceptual only.
When you send a request using IP, it is sent one hop at a time, from one physical network to the next. At each of these hops, an actual transmission occurs at the physical and data link layers."

It is the DATA LINK LAYER which contains the MAC address. And it is exactly what I said, that TCP packets ALL contain MAC addresses (sender AND receiver) therefore, all that needs to be done is to backtrack from the server, through every hop, sniffing the packets for the addys, until eventually, you get to the originating device . . . it's actually conceptually straightforward . . . but I can see that you have no clue about any of this. You can probably barely run your Winblows box . . . this is like talking to a 5 year old, I swear . . . .

This is amusing, this thread will be here for a long time, and ALL THE INFO IS THERE, and it all proves my point, while you keep making an ass out of yourself.

It's almost painful to watch you do it.

[Hammer]

Originally Posted by gonzo

All this big MAC talk makes me want to go get a cookie.

Makes me want a Big Mac.

[moetheman]

Originally Posted by Mediaguy

"The same happens for each subsequent step, until finally, the router nearest the destination sends to the destination using its data link (MAC) address."

Key concept: THE SAME . . . therefore, as I have stated, all that would need to be done is to trace back through the entire sequence, one hop at a time, sniffing the packets to get that hop's sender MAC address, until one arrives at the originating devices.

Just to break it down for you more, MORON, here is
(since I can tell you can't read properly, or you would have seen it, it has been there all along HAHAHAHAHA)
a post in the first thread where this came up:

http://www.oprano.com/msgboard/showp...&postcount=121

which has THIS LINK:

http://www.onlamp.com/pub/a/bsd/2001...SD_Basics.html

which is not a bad piece at all . . . I prefer textbooks myself, but that it right . . . .

Last paragraph on page 1 (yes, at the bottom, there ya GO, champ) has a bit of info you might be interested in reading . . .

Ok, now go on and say that both the author of the textbook and the author of the article are wrong . . . go on . . . you fucking drooling mongoloid imbecile . . . hard to believe you have the nerve to keep going, to keep making an ass out of yourself, in spite of having facts in your face . . . a good, persistent liar AND parasite . . .

[2MuchMark]

First it will be useful to define what MAC addresses are and how they
are normally used.

Definition:
http://en.wikipedia.org/wiki/MAC_address
"Media Access Control address (MAC address) is a unique identifier attached to most forms of networking equipment." Normally a twelve digit hexadecimal number, like: 00-08-74-4C-7F-1D

How it is used:
It's most common use is in the "data link" layer of the OSI model: http://en.wikipedia.org/wiki/OSI_model

When a computer on a network has an IP address it needs to contact it sends out an ARP request to all machines on its network segment (using the broadcast address) and receives an answer from the owner of that address with its mac address. It then stores this in an arp table for later reference. The mac address is then used to send data directly to that computer.
http://en.wikipedia.org/wiki/Address...ution_Protocol

You can view the arp table on a windows XP machine by typing "arp -a" from a command prompt. You can even manipulate the table, though this is not recommended. http://www.mytechsupport.ca/content/view/83/306/

What you will see in your arp table are IP addresses that are on your local network. You will not see any entries for computer beyond your closest router. The reason for this is simple; your computer doesn't care about anythign past that.

All a computer needs to know is how to get to the next router on the way to its final destination (next hop). Once your PC has the mac address of your closest router and hands the data off to it, then it is that next router's job to have the mac address of the next router in line and so on. Each router is only going to keep arp tables with mac addresses of devices that are on the same subnets as they are on.

Remember the way they usually acquire mac addresses is using a broadcast. This will only reach as far as the next router. Routers will not pass on this information. If they did the whole Internet would come to a screeching halt because there would be so many broadcasts that the real data would be choked out. They only need to know how to get to the next hop.
http://en.wikipedia.org/wiki/Broadcast_address

In short, as long as your router is seperated from this server that you are connecting to by at least one other router (which I'm sure that you are) they would not have your mac address in their arp tables. You can see just how many routers are between you by doing a "trace router".
http://support.microsoft.com/kb/162326/EN-US/

First you will see your routers Ip address that is local to your computer, then you will see the address of your local IPS's router, then there will most likely be several other router before finally making to the server you are connecting to.

Each time the data passes through a router the portion of that data that contains the last mac address is pulled out and the current router's is put in. This allows the next router to respond without an arp request to the previous router.

This is a similar discussion:
http://content.ix2.net/arc/t-4333.html
"There is no way to determine the mac address of your computer, once the packets have passed through a router. The mac address is used only on a local network and as a packet leaves your local network, the mac address is
replaced by the mac address of the router. This happens at every router along the route between you and any other site."

Since your computer has an arp table that contains your routers LAN side mac address it is possible that they could send that in the same way they could 2) 3) and 4). But your router is going to have a different mac address for it WAN side, which is the part that you would care about. Your computer will not have the WAN side mac address in its arp table because it is on the "other side" of your router.

All that to say: They only way they could get your router's WAN-side mac address would be have access to a device on your local ISP's network on the same subnet as your router. This is highly improbable. (This all came from http://answers.google.com/answers/threadview?id=765054) by the way).

Anyway,

It appears that I owe MoeTheMan, an apology (Sort of)!

I had said that it was Impossible to detect the MAC address of a machine via the Internet (without a client).
I was RIGHT.

I also said that TCP/IP did not contain Mac address information.
I was WRONG.

MoeTheMan said TCP/IP DID contact Mac information.
He was RIGHT.

However, only the MAC Address information of each hop from one point to the next is known between the devices, but thats it. The original machine does not know the destination's mac address (unless it is 1 hop away such as from a PC to a router), and the destination does not know the original's mac address.

(If all of this info were contained in TCP/IP, the world would explode. So GREG was right!)

MoeTheMan: I will extend a sincere apology to you if you would do the same to me (for at least calling me names). If you don't want to, then thats ok. My apology is out there. For my part, I made a mistake.

[helix]

ahhhh.....So much love in this thread........who is up for a group hug???





anybody?





somebody?





nothing but crickets

[2MuchMark]

Originally Posted by helix

ahhhh.....So much love in this thread........who is up for a group hug???
anybody?
somebody?
nothing but crickets

HUGZ!!!!!!!!!!!

[Nymph]

Originally Posted by helix

ahhhh.....So much love in this thread........who is up for a group hug???





anybody?





somebody?





nothing but crickets

Count me in

[Mediaguy]

Originally Posted by moetheman

Key concept: THE SAME . . . therefore, as I have stated, all that would need to be done is to trace back through the entire sequence, one hop at a time, sniffing the packets to get that hop's sender MAC address, until one arrives at the originating devices.

Just to break it down for you more, MORON, here is
(since I can tell you can't read properly, or you would have seen it, it has been there all along HAHAHAHAHA)
a post in the first thread where this came up:

http://www.oprano.com/msgboard/showp...&postcount=121

which has THIS LINK:

http://www.onlamp.com/pub/a/bsd/2001...SD_Basics.html

which is not a bad piece at all . . . I prefer textbooks myself, but that it right . . . .

Last paragraph on page 1 (yes, at the bottom, there ya GO, champ) has a bit of info you might be interested in reading . . .

Ok, now go on and say that both the author of the textbook and the author of the article are wrong . . . go on . . . you fucking drooling mongoloid imbecile . . . hard to believe you have the nerve to keep going, to keep making an ass out of yourself, in spite of having facts in your face . . . a good, persistent liar AND parasite . . .

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.

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?

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.

[bluemoney]

[helix]

Originally Posted by Nymph

Count me in

[helix]

Originally Posted by 2MuchMark

HUGZ!!!!!!!!!!!

lol...... right back at ya

[gonzo]

Originally Posted by *TAG*

James, I am somehow fascinated with your last name. How is McAnally pronounced?

Coventry.

[helix]

Hmmm........a glitch in the Matrix. Did they cut the hardline?

[gonzo]

Originally Posted by helix

Hmmm........a glitch in the Matrix. Did they cut the hardline?

I spoke the magic word.

More powerful than miserable.

[helix]

I knew it.........you.........are...........the 1

[Buckwheat]

This thread reminds me of the time I hired Jackson Pollack to paint my house . . . What a fucking mess!

[2MuchMark]

And?

And?

Who wants a hug? Hammer? .... Gonzo? ......... Shellee?

Check this out:

http://youtube.com/watch?v=vr3x_RRJdd4

See? This is what Oprano should be all about. Awww! Less fighting and more hugging. (We'll get more chicks that way)

Awww!

m

[Hammer]

Originally Posted by Buckwheat

This thread reminds me of the time I hired Jackson Pollack to paint my house . . . What a fucking mess!

A mess that would be worth millions.

[moetheman]

Originally Posted by 2MuchMark

This is a similar discussion:
http://content.ix2.net/arc/t-4333.html
"There is no way to determine the mac address of your computer, once the packets have passed through a router. The mac address is used only on a local network and as a packet leaves your local network, the mac address is replaced by the mac address of the router. This happens at every router along the route between you and any other site."

That is why I said step back through each "hop". The TCP packets at each hop contain the MAC address of BOTH the SENDER and THE RECEIVER. TO break it down more: you would sniff the addy of the sender in THAT LAST hop. Ok. Then, you trace to the next hop, and sniff there, and do the same, and repeat, until you finally arrive at the originating device . . . as I stated, it is conceptually straightforward.

Originally Posted by 2MuchMark

Since your computer has an arp table that contains your routers LAN side mac address it is possible that they could send that in the same way they could 2) 3) and 4). But your router is going to have a different mac address for it WAN side, which is the part that you would care about. Your computer will not have the WAN side mac address in its arp table because it is on the "other side" of your router.

All that to say: They only way they could get your router's WAN-side mac address would be have access to a device on your local ISP's network on the same subnet as your router. This is highly improbable. (This all came from http://answers.google.com/answers/threadview?id=765054) by the way).

Improbable if you can't manage to enter . . . and it happens EVERY SINGLE DAY. People do this everyday.

Originally Posted by 2MuchMark

Anyway,

It appears that I owe MoeTheMan, an apology (Sort of)!

I had said that it was Impossible to detect the MAC address of a machine via the Internet (without a client).
I was RIGHT.

No one, except you, said that could be done. That would amount to detection without a connection. THAT is not possible.

Originally Posted by 2MuchMark

I also said that TCP/IP did not contain Mac address information.
I was WRONG.

MoeTheMan said TCP/IP DID contact Mac information.
He was RIGHT.

The $100 should go to any charity. I don't care which one, although I prefer:

The WINE project (nothing to do with the drink BTW)
The Free Software Foundation
or the nearest soup kitchen.

Originally Posted by 2MuchMark

However, only the MAC Address information of each hop from one point to the next is known between the devices, but thats it. The original machine does not know the destination's mac address (unless it is 1 hop away such as from a PC to a router), and the destination does not know the original's mac address.

I WROTE THAT. Mayhaps I did not break it down enough, yet I did write that it would be necessary to sniff MAC addresses at each hop, so as to be able to trace back (by looking at the SENDER addy)

Originally Posted by 2MuchMark

(If all of this info were contained in TCP/IP, the world would explode. So GREG was right!)

Funny, he was the only one saying that . . . see point above.

Originally Posted by 2MuchMark

MoeTheMan: I will extend a sincere apology to you if you would do the same to me (for at least calling me names). If you don't want to, then thats ok. My apology is out there. For my part, I made a mistake.

If I thought you were being sincere and honest, I would reciprocate. But I doubt that, so, no apologies from me. And you engaged in name calling as well . . . so don't act like the victim.

You said you were leaving this thread.

[2MuchMark]

If I thought you were being sincere and honest, I would reciprocate. But I doubt that, so, no apologies from me.

No payout. You said you could obtain my pc's mac address. I bet you couldn't, and you couldn't. I won the bet. Sorry, no donation to the ASACP in your name.

No Apology? No worries. I won't lose any sleep over it.

[moetheman]

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.

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.

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.

[moetheman]

Originally Posted by 2MuchMark

No payout. You said you could obtain my pc's mac address. I bet you couldn't, and you couldn't. I won the bet. Sorry, no donation to the ASACP in your name.

No Apology? No worries. I won't lose any sleep over it.

Please post the link to the post where I said I could (and then agreed to) obtain your pc's MAC address.

Do it.

Can it be done? Sure. If I were to break into this server, find your connection, and traceroute it, and sniff the packets at every hop, and mayhaps break into devices along the way, and then break into your LAN . . yet as we know, that would be illegal . . . hell, just breaking into yours, without a notarized letter providing permission, would be asking for it.

[2MuchMark]

ok. thats enough now. no one cares anymore.

[moetheman]

Originally Posted by 2MuchMark

ok. thats enough now. no one cares anymore.

You obviously cared enough to post AGAIN.

Once again, it can be done with software, or with a human.

You were caught posting under another account.

You claimed it was not technologically possible to do so.

That has now been refuted.

[EmporerEJ]

Originally Posted by Nymph

Count me in

ooo ooo....me too!

[KevinG]

I want the 45 minutes of my life back damnit!