|
Home > Archive > Security+ > November 2003 > TCP/IP process question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
TCP/IP process question
|
|
| meijin 2003-11-05, 3:12 pm |
| My appologies to those that see this twice as I posted it in another forum as well...thought some of you gear heads here would be able to help.
===========
Needing a little help here...
Can anyone point me to a website or comment on the process that is gone through when a TCP/IP packet is received by a client device (I am assuming along the guidelines of rfc 1180).
I am recalling a CRC check, checking to see if the packet is a runt, checking to see if the packet is a giant, etc. And then it opens it (if all preliminary tests are passed) and scans the header to get the destination MAC address and see if it is a broadcast address or the client's MAC address).
I need to get the particulars on this and was hoping someone can point me in the right direction.
Thanks! | |
| jdmurray 2003-11-05, 5:04 pm |
| You basically want a functional description of the IP and TCP/UDP parsing and decision procedures that a software engineer would use to write layer 3 and 4 code. This can be found in the excellent book series Internetworking with TCP/IP, Vol.2 by Douglas E. Comer. The book TCP/IP Illustrated, Vol.2 by W. Richard Stevens also has a step-by-step explaination with code. These books were my bibles when I was writing TCP/IP stack code many years ago.
Googling the terms TCP/IP algorithm and TCP/IP implementation only turned up pages like this which described the structure of the packets, but not the algorithm used to parse it. It's not a trivial algorithm, so I'm not suprised. Maybe there's a good discussion of it buried in the comp.protocols.tcp-ip USENET archives. | |
| azimuth40 2003-11-05, 6:04 pm |
| As I recall those books, at least Comers, are pretty pricey unless his question is more detailed than it appears. Another C internals coder, my my.  I didn't realize that Stevens did a separate book, I must look for it. | |
| meijin 2003-11-05, 6:13 pm |
| Thanks for the responses!
No, I don't need anything that indepth. All I am looking at being able to do is a high level "flow" of a packet as it comes into a client adapter to show what all has to be done to get to the point where the "adapter" makes the decision of what (if anything) to do with the packet.
My situation is that I have some folks that have put in some wireless APs that are on the same channel and are close enough that they can all see each other. So, I am trying to demonstrate what a WLAN client has to do with all of this additional traffic.
Make sense or did I just muddy the waters further?
Thanks again for the pointers! | |
| jdmurray 2003-11-06, 12:03 am |
| quote:
Originally posted by meijin
My situation is that I have some folks that have put in some wireless APs that are on the same channel and are close enough that they can all see each other. So, I am trying to demonstrate what a WLAN client has to do with all of this additional traffic.
What you have to realize first is that all Access Points (AP) which are on the same DSSS channel are, in fact, all on the same network. Each AP is configured with an SSID (also called an ESSID) that is essentally the network name. Sometimes you read that an SSID is used to segment a wireless network like a subnet mask, but in reality it works more like the community name string found in SNMP. In other words, it's a very weak form of logical security, like a workgroup name in Windows.
When an AP receives a packet, the first thing it does is check to see if the SSID string matches its own SSID string. If it matches, then the packet is accepted by the AP for further processing, otherwise the packet is ignored and repeated for other APs to receive. What happens to each packet after it makes it past the SSID check depends upon what features you have enabled in your AP (e.g., MAC, IP, and/or protocol filtering, WEP decryption of the payload, etc.).
Your problem is that the other APs on your channel are increasing the number of packets in the air that must be examined by your APs. They are eating up your precious bandwidth and increasing the time required to send data across your wireless network. The other AP is also a security risk if it accepts any packets regardless of their SSID (i.e., it's a sniffer).
quote:
Originally posted by azimuth40
As I recall those books, at least Comers, are pretty pricey unless his question is more detailed than it appears.
Oh heck, just go to a large B&N or Borders, find the books on the shelves, buy a cafe mocha, and sit in an over-stuffed chair and read them. | |
|
|
| darthfeces 2003-11-06, 12:35 am |
| i hope you didn't drop the 2000 punch cards ... | |
| azimuth40 2003-11-06, 1:32 am |
| Thanks JD, both your messages gave me a huge chuckle 
So you remember cutting diode sticks to make gates, that must mean you had bits too. Life was really easy when they invented bits. Magnetostrictive delay lines out of old speaker wire made great memory too.  | |
| jdmurray 2003-11-06, 10:15 am |
| quote:
Originally posted by azimuth40
Thanks JD, both your messages gave me a huge chuckle
So you remember cutting diode sticks to make gates, that must mean you had bits too.
Even back when I was doing stuff like that it was considered severly outdated technology. I punched my last card in (I think ) 1981, and clipped my last diode around '88. I haven't touched a memory drum since high school (nealy 25 years ago  ). |
|
|
|
|
