Thanks - that was a fast and comprehensive answer!!
>The TCP stream analysis code has hardwired into it the notion that IP is
>running directly atop either Ethernet or PPP, with no intervening
>protocols - such as 802.1Q.
>
>It could probably be rewritten to use the new "tap" mechanism, as
>there's now a tap in the TCP dissector; that would make it independent
>of the link layer.
That could really be nice - hopefully that is an exiting job for somebody ;-)
>> Also the capture filter seems no longer to support "vlan" keyword
>> (maybe somewhere in the BPF engine).
>That's an issue of the version of libpcap you're using, not an issue of...
I thought we were using WinPcap2.3 but downloaded it again from
http://winpcap.polito.it/install/default.htm (WinPcap_2_3.exe).
$ ls -l
total 1003
-rwxr-xr-x 1 dxdmap unknown 692007 Jul 26 2002 WinPcap.exe # OLD
-rwxr-xr-x 1 dxdmap unknown 334628 Feb 3 22:45 WinPcap_2_3.exe # NEW
Hmmm - both the packet.dll and the wpcap.dll were different sizes:
#OLD
$ ls -l packet* wpcap*
-rwx------+ 1 Administ unknown 32768 Jul 26 2001 packet.dll
-rwxrwxrwx 1 Administ unknown 131072 Jul 26 2001 wpcap.dll
#NEW
$ ls -l packet* wpcap*
-rwx------+ 1 Administ unknown 61440 Mar 14 2002 packet.dll
-rwx------+ 1 Administ unknown 151552 Mar 14 2002 wpcap.dll
The "vlan" keyword in the capture filter seems to work with the "new v2.3" DLLs.
Anyway we sometimes use our own compilation of packet.dll (compiled with
WPcapSrc_2_3.zip) - to allow us to trace in a remote device....
I made that compilation long time ago - but it looks like an older version
has entered our local FTP server.
/Mads