Re: CSMA/CD
From: K sPecial (xzziroz_at_linuxmail.org)
Date: 08/22/03
- Previous message: Dave Killion: "RE: System Hacked"
- Maybe in reply to: . .: "CSMA/CD"
- Next in thread: Ansgar Wiechers: "Re: CSMA/CD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "Ansgar Wiechers" <bugtraq@planetcobalt.net>, "Security Focus" <security-basics@securityfocus.com> Date: Sat, 23 Aug 2003 01:03:18 +0800
Also take into recognition that there is a difference in length between what's called a "short" jam and a "long" jam. The difference is how far along the line from the sending host that the jam happens, usualy past are worst since if the line is too long and Machine A sends a message to machine B, the interval to wait is 0.9, if the line is long enough where as they had both waited that long And machine A had sent the message to B, B could send a message (legaly) that had followed the rule of waiting the .9, and still have a collision because of the ammount of time it had taken for machine A's message to get to machine B. This is a long collision and the problem here is that if its very long in some cases Machine A can go back into listen mode and not know there was ever a collision if it has transmitted all of it's data before the JAM signal propogates to himself. NICS only recognize a JAM when they are in send mode.
--K-sPecial
----- Original Message -----
From: Ansgar Wiechers <bugtraq@planetcobalt.net>
Date: Fri, 22 Aug 2003 10:30:55 +0200
To: Security-basics@securityfocus.com
Subject: Re: CSMA/CD
> On 2003-08-21 David Gillett wrote:
> > Before a CSMA/CD device transmits, it listens to hear that the wire is
> > clear. (If it isn't, it waits for a while and listens again.)
> > There's a potential race condition where two (or more!) devices
> > listen, find that the wire is clear, and both decide to transmit. Part
> > of resolving this race condition is for each frame transmission to
> > start with a "pad" of known filler.
>
> I may be wrong here, but AFAIK this is not the way padding works.
>
> Say you have two stations located at the two furthermost ends of the
> ether. If one station starts sending, the signal takes some time to
> propagate (since it travels with approximately 0,6 light speed only).
> Now assume the other station starts sending right before the signal
> reaches its port. In the next moment it will receive the first signal,
> detect a collision (this is implemented in hardware AFAIK - something
> like an XOR gate between input and output - since software would not be
> responsive enough to accomplish this task) and a jam signal is sent.
> This station is aware of the collision now, but the first station still
> is not! Only when it receives the signal the second box sent before
> finishing its own transmission, it will be able to detect that a
> collision occured. This is accomplished by defining the minimum frame
> size (64 byte) large enough to make sure a station keeps sending at
> least the time a signal needs to cover twice the maximum segment size
> ("there and back again").
>
> So where does pad fit in here? Unfortunately, en empty eternet frame
> (headers only) is smaller than 64 byte (just 18 byte: destination
> address, source address, type, FCS), so every frame smaller than 64 byte
> is filled up with zeroes (or maybe even garbage, I'm not sure) to have
> the required minimum size. This fillup is called pad.
>
> Regards
> Ansgar Wiechers
>
> ---------------------------------------------------------------------------
> ----------------------------------------------------------------------------
>
-- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze --------------------------------------------------------------------------- ----------------------------------------------------------------------------
- Previous message: Dave Killion: "RE: System Hacked"
- Maybe in reply to: . .: "CSMA/CD"
- Next in thread: Ansgar Wiechers: "Re: CSMA/CD"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|