homeGeek CultureWebstoreeCards!Forums!Joy of Tech!AY2K!webcam

The Geek Culture Forums


Post New Topic  New Poll  Post A Reply
my profile | directory login | | search | faq | forum home
  next oldest topic   next newest topic
» The Geek Culture Forums   » Other Geeky Stuff   » Ask a Geek!   » Promiscuous Mode

 - UBBFriend: Email this page to someone!    
Author Topic: Promiscuous Mode
spungo
BlabberMouth, a Blabber Odyssey
Member # 1089

Member Rated:
4
Icon 1 posted June 02, 2011 06:53      Profile for spungo     Send New Private Message       Edit/Delete Post   Reply With Quote 
Ok, this is something that has bothered me for a long time -- if promiscuous mode allows a NIC to see every packet on the LAN, how does the switch (or hub) know that your NIC has promiscuous mode enabled? Is it part of the underlying hand-shaking that goes on between a NIC and a switch? Any help greatly appreciated.

Edit: ok, I think I understand it now: the switch knows nothing about the promiscuous (or not) setting of the card -- it simply sends all unicast (addressed to that NIC) + all multicast + broadcast traffic on the LAN -- as it does to every node on the LAN. Promiscuous mode on the card is just a filter -- when enabled, it will send every frame up to the CPU, as opposed to just the unicast frames which is all it sends upstream when NOT in promiscuous mode. This sounds reasonable, but it means that when some process on that node sends out a multicast join request, the card would have to keep tabs of this, otherwise it wouldn't know to pass multicast packets up to the CPU (when NOT in promiscuous mode!)

I didn't know NIC cards were sophisticated enough to know when a process above has sent multicast join requests. [Confused]

--------------------
Shameless plug. (Please forgive me.)

Posts: 6523 | From: Noba Scoba | Registered: Jan 2002  |  IP: Logged
dragonman97

SuperFan!
Member # 780

Member Rated:
4
Icon 1 posted June 02, 2011 14:23      Profile for dragonman97   Author's Homepage     Send New Private Message       Edit/Delete Post   Reply With Quote 
Close...and obviously smart to ask/think of it.

*Switches* do not send every unicast packet to every node. They maintain an address table that keeps track of the MAC addresses of destinations (well, technically source, but more relevant for return), and only send the relevant packets there. Hubs, OTOH, have no such concept and send packets everywhere except to the device that sent them. (Which is incidentally, where the loopback interface came from - the need to be aware of such packets.)

As to multicast, I'd like to give a better answer on that (I'm not willing to wing it -- I'll crack open my CCNA books tomorrow. [edit: mostly scratch that; see postscript]

Real life example: I run a captive portal system that occasionally presents issues for clients (read: computers) that have legitimate, not-to-be-captured, DNS requests. Every so often, a new such destination comes on the scene, and fixination [sic ;] is needed to let it go through. I fire up a laptop with Backtrack, throw it and the client on a hub, and plug that into the relevant network. With the laptop in promiscuous mode, it can see every DNS request presented by the client, and every response sent to it. This works on a hub, because the packets are sent to everyone on that segment. With a switch, the client's DNS request would go straight to the DNS server (likely via the uplink port), and the response would go straight to the client. The promiscuous laptop would just sit there all alone, with no one to buy it drinks, or even to see any packets going by, save for broadcasts (such as ARP & DHCP).

P.S. A quick skim on ICND1 speaks of IP multicasting, where a good deal of it happens at the IP level...but interestingly enough, points out that a special multicasting MAC address is used (prefix: 01:00:5e), which would keep it from getting caught up in the aforementioned MAC addr. table. Neat. (I may want to play with this in Wireshark...) I'm pretty sure the long and short of it is: Clients seeking to receive multicast packets would simply use that address (i.e. 'subscribe' / 'listen' to it) and clients that aren't interested will similarly drop said packets (i.e. the same way they ignore unicast packets not meant for them). I don't think it's as complicated as whatever page you came across.

--------------------
There are three things you can be sure of in life: Death, taxes, and reading about fake illnesses online...

Posts: 9208 | From: Westchester County, New York | Registered: May 2001  |  IP: Logged
quantumfluff
BlabberMouth, a Blabber Odyssey
Member # 450

Member Rated:
5
Icon 1 posted June 02, 2011 15:17      Profile for quantumfluff     Send New Private Message       Edit/Delete Post   Reply With Quote 
dragonman is exactly right.

I just want to add that you can't always count on a switch *not* broadcasting packets. One well known hacking technique is to spoof packets from the address of the target host, so trick the switch into sending traffic to your port. For better isolation I think you have to have a switch that support VLAN, but that is generally commercial grade.

Posts: 2867 | From: 5 to 15 meters above sea level | Registered: Jun 2000  |  IP: Logged
quantumfluff
BlabberMouth, a Blabber Odyssey
Member # 450

Member Rated:
5
Icon 1 posted June 02, 2011 15:18      Profile for quantumfluff     Send New Private Message       Edit/Delete Post   Reply With Quote 
and not to disappoint our readers...

The last time I was in promiscuous mode my wife found out. Next time I'll be more careful.

Posts: 2867 | From: 5 to 15 meters above sea level | Registered: Jun 2000  |  IP: Logged
spungo
BlabberMouth, a Blabber Odyssey
Member # 1089

Member Rated:
4
Icon 1 posted June 03, 2011 00:28      Profile for spungo     Send New Private Message       Edit/Delete Post   Reply With Quote 
Thanks a lot guys -- that really helps.

I should explain what it is I'm actually trying to do: I want to multicast on a LAN, but I don't want the switch to even send the multicast packets to nodes that haven't sent IGMP join requests. This is harder that it sounds: with a switch being a layer 2 device, it doesn't inheritly understand IGMP (the packets of which are typically destinated for a router). Anyway, our switch is supposedly capable of IGMP snooping, and I'm just trying to veryify that the setup is working correctly.

Cheers.

--------------------
Shameless plug. (Please forgive me.)

Posts: 6523 | From: Noba Scoba | Registered: Jan 2002  |  IP: Logged


All times are Eastern Time  
Post New Topic  New Poll  Post A Reply Close Topic    Move Topic    Delete Topic next oldest topic   next newest topic
 - Printer-friendly view of this topic
Hop To:

Contact Us | Geek Culture Home Page

© 2014 Geek Culture® All Rights Reserved.

Powered by Infopop Corporation
UBB.classicTM 6.4.0



homeGeek CultureWebstoreeCards!Forums!Joy of Tech!AY2K!webcam