Hardware MAC addresses are supposed to be globally unique. All that really matters, though, is that they be unique within a given network. If you have duplicate MAC addresses on a shared-media network, you can get weirdness like you describe, although if the TCP sequence numbers are verified then it gets harder -- C's attempt to disrupt the conversation may get discarded at the TCP layer. If you have duplicate MAC addresses on a *switched* network, this looks to the switches like a loop in the network. Most implement STP (Spanning Tree Protocol) to detect loops and break them by shutting down just enough interfaces to make the loop go away, so odds are that one of the duplicates gets disconnected.
David Gillett > -----Original Message----- > From: Stuart [mailto:[EMAIL PROTECTED] > Sent: July 24, 2003 10:04 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: ARP Spoof Question > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for clearing that up, > I remember reading an article a while back about sending frequent > spoofed ARP packets to receive packets but have been unable to locate > the article. You can specify your own Mac address on some network > cards in windows now, if this was set wouldn't this prevent proper > communications between hosts? > Such as A sending a SYN packet > B replying with SYN/ACK > And C (change MAC) replying with FIN > Will this cause the connection to close preventing connectivity? > > Thanks > > Stu > > > - -----Original Message----- > From: David Gillett [mailto:[EMAIL PROTECTED] > Sent: 24 July 2003 17:39 > To: 'Stuart'; [EMAIL PROTECTED] > Subject: RE: ARP Spoof Question > > A switch should *always* be learning. A destination MAC > address should always fall into one of two categories: > > 1. I have it in my switch table (NOT *ARP*, per se), because > I saw traffic from it on interface X within the last N time-units. > > 2. It's not in my tables -- send this packet to every port and > assume we'll see a packet from it soon so it will get added to > my switch table. > > Switch table entries could get created when ARP response packets > are seen -- or ARP requests, or DHCP broadcasts, or .... > > David Gillett > > > > -----Original Message----- > > From: Stuart [mailto:[EMAIL PROTECTED] > > Sent: July 23, 2003 16:13 > > To: [EMAIL PROTECTED] > > Subject: RE: ARP Spoof Question > > > > > > If we use a Cisco switch for example, don't they have a > > learning period? > > I would presume that the switch would go through the process > > of building > > its ARP tables again. > > > > Stu > > > > -----Original Message----- > > From: Simon Gray [mailto:[EMAIL PROTECTED] > > Sent: 23 July 2003 17:10 > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: ARP Spoof Question > > > > >Q1.My Question is, Node C will also reply to that request of > > Node A. SO > > >now Node A has 2 different MAC for the same IP. How is Node > > A handling > > >this situation??? > > >Q2.The switch also updates its table of IP/MAC address > > bindings, so how > > >is switch handling this situation??? > > >Is it "first-come-first-serve" methodology which Node > > A/Switch takes??? > > > > I don't know how correct this is, but I would of thought the Node > > A/Switch > > would update whatever stored record of IP/MAC it has with the new > > details. > > > > Simon > > > > > > -------------------------------------------------------------- > > ---------- > > --- > > -------------------------------------------------------------- > > ---------- > > ---- > > > > > > > > -------------------------------------------------------------- > > ------------- > > -------------------------------------------------------------- > > -------------- > > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 > > iQIVAwUBPyARjZMRMj30dWmZAQIQVw//Z/h3UPG4X3eg29UGr9OChIXHQj+bc90j > 5WLIXXZ9ec5yBHCkqqz6wjbY1foUmqzAsVakjnSLjidy7LyRbJhTLTJsopp9s92B > L/hMh4HxLEBuHe7L5hMh5KKAsldeorycF0S/Sgfjm/5DRkL2xpSfqtJQttSqPMrL > jxWn2EF5vbaRKUX/CsGPWKPKSnwZ85zaYxWUIatM3uyiotaeDsYdzgupKOHdqaHm > FxUT4qKINE5z2kXuUBUyOiypwd/FgabPmy6bg5IV9wLthfQCSUpnjqe2ObwWmaCT > JkWFtBpn3lWBy2qwNahFrzSdPVTDJ6Mo+Hjb6ZAfGvGqVoz99VdR+7zpJaoMC9mD > 6aQRWkgZrxJKYzgXLxhxAdliOa/ovTGaz1y0bv1hfjuuvRPuwjdpT7DcpOwscQNY > kBlCfkhuzJ1gD2A0PE62iDdUdnJeBPWVUVAKRkPQfV1d9k2J5k6UxYxfQPbO4ZfM > NVnR1RszjLl38eTeQpq3uD0K2BK0vjquOvBh/fZF92W+ctrkfecrubCIl0MC1S9q > RReJqjGxxj7qZs/sCtrKZt+3T7ahSkuMuvlYwcEw4UBnPpDtl0iacabVZjHuu+lE > 3uD+UAxbRaNxG+fX7IOQNQy0LvJgx9Zg2G2pTsrNLUawpNOAT6Y/z4Zb00Fgu9xU > 8UgW8toGn20= > =/E3X > -----END PGP SIGNATURE----- > --------------------------------------------------------------------------- ----------------------------------------------------------------------------
