RE: CSMA/CD
From: K sPecial (xzziroz_at_linuxmail.org)
Date: 08/22/03
- Previous message: Dave.Hartley_at_uk.delarue.com: "SNORT config Question"
- Maybe in reply to: . .: "CSMA/CD"
- Next in thread: Brian Rogalski: "Quality and Comprehsive Services"
- Reply: Brian Rogalski: "Quality and Comprehsive Services"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: ajfomania@hotmail.com, "Security Focus" <security-basics@securityfocus.com> Date: Fri, 22 Aug 2003 12:35:17 +0800
I had came up with this exact idea at a point in reading, Allthough I basicly did not look to much further when I realized that CMSA/CD is incorperated in a chip on the Network card and that the signal (i believe) is an electrical difference and nothing to do with a packet whats so ever. I hope this helps your compulsing.
--K-sPecial
----- Original Message -----
From: "David Gillett" <gillettdavid@fhda.edu>
Date: Thu, 21 Aug 2003 15:59:04 -0700
To: "'. .'" <ajfomania@hotmail.com>, <Security-basics@securityfocus.com>
Subject: RE: CSMA/CD
> 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.
> The CD (collision detection) piece comes into play at that point.
> If no race condition has occurred, the part of the hardware that
> listens to the wire will hear only its own filler. Anyone who
> shows up late and listens to hear if the wire is clear will also
> hear the filler, and wait.
> If the listener hears anything else, then it must be because
> someone else is ALSO putting out filler on the wire (i.e., the
> race condition occurred); since there's only one "band", the two
> transmissions "collide" and no listener can separate them.
> Having detected a collision, the device aborts transmission of
> the frame data, waits some random time, and goes back to listening
> for a clear line. (The wait time is randomized so the same pair
> of devices don't collide again on the same frames.)
>
>
> > If the trying host gets 15 jam signals at one time, it times out.
>
> I think the spec is that if 15 retry attempts on a frame all
> encounter collisions, the frame is dropped. That's not quite the
> same thing.
>
> > Is there any possibility to write a program that sends jam
> > signals to other hosts within the same broadcast domain until
> > they timed out and died?
>
> The filler isn't aimed at any particular host, it's visible to
> everyone on the *collision* domain. There isn't a way to do this
> into other collision domains, even if they happen to be in the
> same broadcast domain.
> At worst, you could issue a stream of filler and deny service to
> every other device on the collision domain. They wouldn't "die",
> they'd just be forced to discard frames that couldn't be sent.
>
> > Does this mean that IF you were to write this program, you'd
> > actually need to rewrite a part of the tcp/ip protocol stack?
>
> As someone else has pointed out, this is probably normally done
> as part of the Ethernet port hardware. At best, it might be in
> driver code. Since Ethernet can be used to carry AppleTalk,
> DECNet, IPX, etc, it's not in the TCP/IP part of the stack.
>
> > Isn't this a big issue?
>
> No. A Denial-of-Service that, by definition, has to include
> yourself, and requires physical access to the target LAN segment,
> is somehow not that interesting to attackers.
>
> David Gillett
>
>
> > -----Original Message-----
> > From: . . [mailto:ajfomania@hotmail.com]
> > Sent: August 21, 2003 04:08
> > To: Security-basics@securityfocus.com
> > Subject: CSMA/CD
> >
> >
> > Hi there!
> > I'm currently reading a CCNA book, and I've got some
> > questions I can't find
> > an answer to.
> > The Carrier Sense Multiple Access with Collision Detection
> > checks if there
> > is any traffic on the wire and then starts to send the host's
> > data, if
> > someone tryes to send at the same time, the sending host
> > sends the "trying"
> > host a jam signal that would make the trying host to wait.If
> > the trying host
> > get's 15 jam signals at one time, it times out.
> >
> > Some questions came up at this chapter. Is there any
> > possibility to write a
> > program that sends jam signals to other hosts within the same
> > broadcast
> > domain until they timed out and died ? Does this mean that IF
> > you where to
> > write this program, actually needed to rewrite a part of the tcp/ip
> > protocol stack ? Isn't this a big issue?
> >
> > Sorry for my bad english..
> >
> > Best Regards: Fredrik Wessberg
> >
> > _________________________________________________________________
> > Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/
> >
> >
> > --------------------------------------------------------------
> > -------------
> > --------------------------------------------------------------
> > --------------
> >
>
>
> ---------------------------------------------------------------------------
> ----------------------------------------------------------------------------
>
-- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze --------------------------------------------------------------------------- ----------------------------------------------------------------------------
- Previous message: Dave.Hartley_at_uk.delarue.com: "SNORT config Question"
- Maybe in reply to: . .: "CSMA/CD"
- Next in thread: Brian Rogalski: "Quality and Comprehsive Services"
- Reply: Brian Rogalski: "Quality and Comprehsive Services"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|