[Winpcap-users] [ANNOUNCE] WinPcap 3.1 has been released
mryan at pcsentinelsoftware.com
Mon Aug 8 23:32:25 GMT 2005
Thanks for all your hard work on this project!
>From: Gianluca Varenni [mailto:gianluca.varenni at gmail.com]
>Sent: Friday, August 5, 2005 05:15 PM
>To: winpcap-users at winpcap.org
>Subject: [Winpcap-users] [ANNOUNCE] WinPcap 3.1 has been released
>After more than two years of hard work, the final version of WinPcap 3.1 is
>available from today in the download section of the WinPcap website,
>This new release represents an important milestone for the project: major
>improvements and bug fixes have been carried out during this long period of
>time, and the result is the most stable and reliable version of WinPcap in
>its history. Thanks to all the users that contributed to this result by
>submitting bug reports and thoroughly testing the several betas that were
>Changelog from WinPcap 3.1 beta4
>- New installation script based on the NSIS installer. The new installer
> should be able to detect any previous version of WinPcap, remove it on
> request and install the new version, decreasing the number of situations
> in which a reboot is necessary. Moreover, by connecting to the WinPcap
> website, the installer is able to tell the user if more recent versions of
> WinPcap are available.
>- wpcap.dll has been updated to libpcap 0.9.3 from http://www.tcpdump.org.
>- General cleanup of the documentation (now aligned to libpcap 0.9.3).
>- Modified the documentation, so that packet.dll is no longer available in
> the standard developer's pack.
>- Added to the developer's pack a set of libpcap-compatible samples,
> suitable to be compiled against vanilla libpcap
>- Exported the following new functions from wpcap.dll: pcap_list_datalinks()
> and pcap_dump_ftell().
>- Removed pcap_file() from the exports because of incompatibilities with the
> Microsoft C runtime (CRT).
>- General cleanup of the existing samples.
>- Renamed the NdisWanAdapter to GenericDialupAdapter, to make the use of
> this adapter more clear for the users.
>- Removed some useless files in the source tree and in the documentation.
>- Bug fixing:
> + Fixed several bugs in the kernel BPF filter function when the packet is
> stored into two not contiguous buffers. This bug shows up as missing
> packets in the capture while the machine is using personal firewalls and
> certain antivirus softwares.
> + Fixed a problem related to the NetMon COM component initialization. This
> bug caused random access violation errors while listing the adapters.
> + Removed a duplicated initialization of an event in the driver.
> + Added a check in packet.dll that prevents listing and opening of
> FireWire adapters, since they have a broken interface with NDIS and can
> cause blue screens.
> + Fixed a memory leak in PacketGetAdaptersIPH().
> + Fixed a check that could cause PacketSendPackets() to crash packet.dll.
> + Minor fixes.
>Changelog from WinPcap 3.1 beta3 to WinPcap 3.1 beta4
>- wpcap.dll has been updated to libpcap 0.8.3 from http://www.tcpdump.org.
>- Added a note in the documentation that states that the kernel dump feature
> is disabled due to incompatibilities with the new kernel buffer.
>- Minor fixes to the documentation
>- Removed some useless files.
>- Bug fixing:
> + Fixed a bug related to COM initialization in WanPacket, by which
> WanAdapters were not working correctly if the calling thread was using
> COM with a different threading model.
> + Fixed a problem in AddAdapterIPH(), by which no adapter was actually
> added with this function because of a UNICODE/ASCII mismatch. Basically,
> AddAdapterIPH received an ASCII adapter name, and tried to open it with
> PacketOpenAdapterNPF, which accepts UNICODE strings, only.
> + Fixed a bug in the remote capture code due to concurrency issues when
> spawning a new thread
> + Fixed a problem related to the generation of grammar files with flex
> in the CygWin makefile.
> + Fixed a couple of memory leaks in PacketGetAdapterNames().
> PacketGetAdapterNames() seems to be still leaky, but the source of the
> leak seems to be a leaky API in the Microsoft IpHelperAPI, at least on
> WinXP SP1.
> + Added some code that frees the global list of adapters when packet.dll
> is unloaded (i.e. when DllMain is called with DLL_PROCESS_DETACH)
> + Fixed a bug that caused the adapters not to be listed on terminal
> services. The bug was caused by the lack of the "\\global" prefix in
> front of the adapter names.
> + Fixed a bug related to adapter opening in the pcap_filter example. Fixed
> the usage string that was wrong.
> + Fixed a bug in the JIT code of the driver that could potentially cause a
> BSOD if two threads try to set a filter (that will be jitted) at the
> same time.
> + Fixed a bug by which the driver fails to return any packet with a read
> after an IOCTL_SETBUFFER has changed the buffer size. The bug is due to
> some missing counter resets.
> + Fixed some debugging messages in the NT driver that were not macroed
> with IF_LOUD
>Changelog from WinPcap 3.1 beta2 to WinPcap 3.1 beta3
>- Bug fixing:
> + Fixed a bug related to device listing if TCP/IP is not installed: on
> 2000/XP if TCP is not installed, it reported "you must install TCP/IP",
> and this was plain wrong.
> + Added PacketSetSnapLen() under Win9x. Without this function, wpcap.dll
> fails to load on Win9x.
> + PacketGetAdapterNames() has been rewritten under Win9x, in order to
> comply to the correct behavior specified in the documentation.
>Changelog from WinPcap 3.1 beta to WinPcap 3.1 beta2
>- Added some code to show a fake NdisWan adapter, useful to capture LCP/NCP
> packets. This adapter is always listed on 2000/XP/2003 (if you have enough
> privileges), even if you don't have any PPP/VPN/... connection
>- Added a check in the installer, so that the installation fails if you
> don't have administrator privileges.
>- Added a check so that NdisWan adapters (PPP, VPN, ...) are listed only if
> you can capture from them.
>- Added a new sample program, which gets the MAC address of an interface
> using packet.dll
>- Modified the access to the global list of adapters in packet.dll under
> NT4/2000/XP/2003. Now packet.dll should be thread-safe.
>- Bug fixing:
> + fixed some resource leaks in the remote capture daemon (rpcapd).
> + fixed a couple of resource leaks in packet.dll.
> + fixed some meaningless last error messages set by PacketOpenAdapter
> (e.g. "The operation completed successfully").
> + fixed a shortcoming in pcap_findalldevs, by which the adapters where not
> listed if they couldn't fit into a 8kB buffer.
> + fixed a memory leak in pcap_lookupdev.
> + fixed some bugs related to adapters listing:
> * some adapters were not listed, especially if some registry keys are
> messed up.
> * in some situations the listing failed with the message "Attempt to
> release a mutex not owned by caller"
> * if PacketGetAdapterNames() failed, it returned the wrong number of
> needed bytes for the input buffer.
> + fixed a buffer overrun in npf.sys that caused crashes (BSODs) when
> there are too many adapters in the registry.
> + fixed a bug in npf.sys that caused blue screens (BSODs) when you try to
> send "jumbo" packets, i.e. packets bigger than the maximum frame size
> for the selected link type.
> + minor bug fixes.
>Changelog from WinPcap 3.01 alpha to WinPcap 3.1 beta
>- Support for capture on NdisWan, with the following features:
> + Based on the NetMon API, does NOT use NPF.sys
> + Works with PPP (dial-up) and VPN links
> + Works on Windows 2000 and XP, only
> + Packet transmission is not supported
> + packet filtering is done at user level
>- wpcap.dll has been updated to libpcap 0.8.1 from www.tcpdump.org.
>- Support for DAG cards, based on the Windows version of the 2.5 Endace Dag
>- The method used by the driver to timestamp packets can now be changed
> without recompiling the driver, modifying a registry key:
> Possible values are
> - 0 (default) -> Timestamps generated through KeQueryPerformanceCounter,
> less reliable on SMP/HyperThreading machines,
> precision = some microseconds
> - 2 -> Timestamps generated through KeQuerySystemTime,
> more reliable on SMP/HyperThreading machines,
> precision = scheduling quantum (10/15 ms)
> - 3 -> Timestamps generated through the i386 instruction RDTSC,
> less reliable on SMP/HyperThreading/SpeedStep machines,
> precision = some microseconds
>- The driver is now started by the SCM with GENERIC_READ privileges rather
> than ALL_ACCESS. This allows not-administrator users to start and run
>- Changes to the wpcap.dll API:
> + pcap_findalldevs() and pcap_findalldevs_ex() return IPv6 addresses
> + pcap_findalldevs_ex() is now able to list local adapters, remote
> adapters, and the list of capture files present in a given folder.
>- Changes/additions to the Packet.dll API:
> + The code to gather interface information has been mostly rewritten, in
> order to be more modular and source independent. IP Helper API is now
> used in addition to registry scanning.
> + PacketGetNetInfoEx() now returns IPv6 addresses besides IPv4 ones.
> + modified the format of the npf_if_addr structure, that
> PacketGetNetInfoEx() uses to return the network address of an
> interface. In order to provide enough space for an IPv6 address,
> npf_if_addr is now made of three struct sockaddr_storage rather than
> three struct sockaddr.
> Since the former is 128 bytes while the latter is 16 bytes, old
> applications will not be compatible with the new PacketGetNetInfoEx().
> + PacketGetAdapterNames() now returns the names of the adapter in ASCII
> rather than in Unicode.
> Since the main purpose of PacketGetAdapterNames() is feeding data to
> pcap_findalldevs() and since pcap_findalldevs() needs ASCII names, the
> new PacketGetAdapterNames() avoids a conversion in wpcap.dll and
> uniforms the data format with the one of Windows 9x (this potentially
> simplifies the code of the applications). As a consequence to
> this modification, old applications won't work properly with the new
> PacketGetAdapteNames() on NT/2k/XP/2k3.
> + PacketOpenAdapter() now takes an ascii adapter rather than a UNICODE
> one. This is a consequence of the fact that PacketGetAdapterNames()
> returns ASCII strings: they can be immediately passed to
> PacketOpenAdapter(). (note: internal conversion is provided so that a
> UNICODE adapter name will be correctly opened, however the prototype
> changes and this could generate warning when compiling old
> + For the same reason, PacketGetNetInfoEx() takes an ASCII adapter
> string rather than a UNICODE one. Internal conversion is provided for
> backward compatibility in this case, too.
> + PacketGetVersion() now retrieves the version number from the dll
> + Added a PacketGetDriverVersion() function that returns the version
> number of NPF.sys.
>- Packet sampling
> + added the capability to perform packet sampling instead of just packet
> capture. This feature can be turned on through the new
> pcap_setsampling() function.
> + This feature is available on local captures, offline captures, and
> remote captures.
> + Please note that this feature is highly experimental.
>- Remote capture
> + Improved support on FreeBSD and Linux.
> + Fixed a bug in UDP data trasfer
> + Support for packet sampling (only if the remote daemon runs on a Win32
> machine; it does not work on Linux and FreeBSD).
> - Updated the documentation
> + Many examples have been rewritten in order to use the new pcap_open()
> and pcap_findalldevs_ex() functions.
>Changelog from WinPcap 3.0 to WinPcap 3.01 alpha
>- Modified interface for function pcap_findalldevs_ex in order to support
> local files listing
>- pcap_findalldevs_ex supports local device, remote device, and local file
>- Updated makefiles in order to compile on UNIX
>- Support for remote capture (and remote daemon) in Linux and BSD (in
> addiction to Win32)
>- Simplified architecture for the remote capture; now pthreads are needed
> only by the rpcapd daemon; standard libpcap does no longer need phtreads
>- Added initial support for remote packet sampling (local packet sampling is
> still to be done)
>- pcap_fileno returns a valid description also in case of a remote capture,
> so that the 'select()' function can be used to check if packets are
> waiting to be read
>- Improved docs
>- Started modifying the Developer's Pack examples in order to use the new
> system calls (pcap_open, pcap_findalldevs_ex, etc), although this process
> has not been completed
>- Bug fixing:
> + Fixed a bug that prevented the remote capture (active mode) working in
> Windows XP
> + Fixed a bug that caused the driver not to list any adapter under
>Winpcap-users mailing list
>Winpcap-users at winpcap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Winpcap-users