We ran into a similar problem with the Intel PRO/100 and PRO/1000 NIC cards. In this case, we were unable to sniff packets that were not sent to the machine we were running the sniffer on. It seems that the newer Intel drivers have built-in network traffic "smarts" that prevent the NIC from passing up packets that are not meant for that machine. In essence, it was not a true promiscuous mode capture.
We ended up talking with Intel. For the PRO/100, we were told that we could add an undocumented entry in the registry that would enable promiscuous mode. For the PRO/1000, Intel released a newer version of the driver that fixed the issue. I don't know if you are seeing a similar issue, but you may want to search the Intel site to see if this is an issue with their new driver and if there are any workarounds. Thank you, "God does not play dice!" -- Albert Einstein "Not only does God play dice with the Universe - he sometimes casts them where they can't be seen." -- Stephen Hawking -----Original Message----- From: Guy Harris [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 4:50 AM To: [EMAIL PROTECTED] Subject: Re: [WinPcap-users] winpcap and the new Intel 2200BG drivers (Win XP Pro SP1) Adam Steiner wrote: > Just wanted to thank the guys that replied and give an update: > > I ran into someone else with a similar issue. Apparently the old > version of winpcap (or ethereal or the combo) Ethereal only interacts with network interfaces through libpcap/WinPcap, so it's extremely unlikely that the version of Ethereal made a difference. > didn't fail when it was > told to capture in promiscuous mode, but it just captured the packets > coming to it. The new version (or combo) fails when trying to place the > card in promiscuous mode, and while it doesn't throw an error, it also > doesn't capture any packets. I.e., with the *same* version of the driver, different versions of WinPcap exhibit different behavior? And what do you mean by "fail"? I'd define "fail" as "not putting the interface into promiscuous mode", and either 1) returning no error (i.e., silently failing) or 2) returning an error. When you say "just captured the packets coming to it", by "the packets coming to it" do you mean broadcast and multicast packets, and unicast packets sent to the MAC address of the interface, or do you mean all packets on the network with which the interface was associated, except for packets sent by the interface? If the former, then it did fail, in the sense that the interface wasn't in promiscuous mode (unless nobody else was transmitting anything on that network). If the latter, this appears to be a common problem with drivers on Windows (perhaps they interpret "promiscuous mode" as meaning "give the host all packets that the interface receives" rather than "give the host all packets on the networks, including the ones the host sends"; for some reason, Ethernet drivers on Windows seem to interpret "promiscuous mode" in the latter sense). Some drivers also show the "no packets at all" behavior. Basically, for some reason, 802.11 driver writers on Windows seem to do an almost uniformly bad job of handling promiscuous mode. Linux and BSD driver writers (including the Airport driver writers at Apple) largely do a better job - promiscuous mode works, and captures both incoming packets from other machines on the same wireless network *and* outgoing packets, and some drivers even support "monitor" or "rfmon" mode, where it captures all packets that the radio receiver sees, and supplies management (and possibly control) packets to the host, with all packets coming with 802.11 headers rather than fake Ethernet headers. People who want to capture and analyze traffic on wireless networks with an x86-based PC are advised either to 1) buy a commercial program such as Sniffer Wireless or AiroPeek, *if* the program in question has a driver for their wireless interface (those programs include their own drivers, which is how they get around the problems with the vendor's drivers) or 2) run some Linux distribution or one of the BSDs, if the OS in question has a driver for their neetwork interface (and, ideally, if it supports monitor mode: http://www.ethereal.com/faq#q5.38 http://www.ethereal.com/faq#q5.39 http://www.ethereal.com/faq#q5.40 It would be Truly Wonderful if Microsoft 1) laid down the law as to what "promiscuous mode" is supposed to mean, and say "it means that packets sent *by* the machine should be seen" (or, if the code that doesn't wrap those packets around in promiscuous mode is their code, fix that code) and 2) came up with a standard mechanism for putting 802.11 cards into monitor mode, with 802.11 headers supplied, and encouraged 802.11 driver vendors to support it although both of those probably won't happen until Longhorn ("Native 802.11 support: http://www.microsoft.com/whdc/device/network/802x/Native80211.mspx *might* allow a network analyzer to get 802.11 headers through NDIS, but I don't think it adds a standard OID to put an interface into monitor mode or standardizes what a driver should do with outgoing packets in promiscuous mode). For extra credit, they should also 1) supply "radio information" such as signal strength information with received packets and 2) if they don't do so already, have a standard OID to control the channel for a wireless interface. ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED] ================================================================== ================================================================= This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED] =================================================================
