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]
==================================================================
