Ulf,
Ulf Lamping wrote:
Loris Degioanni wrote:
Probably more, but be careful: most of them are optional, and almost
no boards implement them.
Yes, I've noticed that too. I check every return value and will show
simply '-' if that specific function failed, so this shouldn't be a
problem. Trying to show all the values is the best I can do on this. I
hope no NDIS driver will just crash when simply asking the "correct
question", but you'll never know ...
This shouldn't happen. However, there is a OID_GEN_SUPPORTED_LIST that
you could perhaps use for this purpose.
Moreover, a lot of them are very techincal (winpcap just opens a
connection to NdisRequest, which is used by protocol or intermediate
drivers to query NIC drivers) and are of few interest to user level
users.
Well, I would guess that Ethereal users are usual technical staff...
>
So some will be interested in that info while others may not. E.g. I was
asked several times if it's possible to show the Ethernet FCS failures
somehow.
The information about the WLAN BSSID list (showing the available remote
stations) *is* probably very useful even for the normal user.
If you apply these restrictions, you start to fit a lot better inside
pcap_if.
Don't understand you here?!?
Please prove me wrong, and I'll be happy to add additional libpcap info
to the Ethereal GUI ...
I don't think it's a matter of proving anything. I'm very Windows
oriented, probably even more than you, but I just gave my 2 cents
about how I'd like the thing to look.
And I 100% agree with you, but have to face the facts ... ;-)
Said that, I'm very happy about any addition to Ethereal you want to
make, especially because I added this precise feature to Analyzer 6
years ago.
Hmmm, we might sit down and have a beer together someday ...
Where do you live? :-)
just be careful to check the version of packet.dll you use, and to
inform the users *very clearly* about the winpcap version they'll have
to install, because your code will not be compatible with past versions.
Do you have detailed information in which version the functions:
PacketOpenAdapter, PacketCloseAdapter and PacketRequest *are* available
in it's current form (e.g. parameters unchanged)? As far as I see it, at
least all current 3.x versions should work. What about the 2.x versions?
From http://www.winpcap.org/misc/changelog.htm:
Version 3.1 beta1, 3 feb 04.
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 of 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
applications).
* 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
binary.
* Added a PacketGetDriverVersion() function that returns the
version number of NPF.sys.
* The structure NetType has been modified to support link layers
faster than 4 gigabits: the size of the LinkSpeed field is now 64 bits
instead of 32 bits. This impacts on the PacketGetNetType() function too.
As a consequence of this modification, old applications won't work
properly with the new PacketGetNetType().
This means that versions before 3.1 beta1 will not be compatible.
Packet.dll has a function called PacketGetVersion() that you can use to
conditionally run your code.
If you don't do that, the users will see "random" crashes in
packet.dll, and they will almost surely complain with me and the other
winpcap developers...
I currently don't do that check and have to add it somehow. You guys are
doing a great job and I don't want to give you work I have to do ;-)
If you would like to see the results, you could download the current
buildbot build from:
http://www.ethereal.com/distribution/buildbot-builds/, revisions since
SVN 14408 includes the new feature.
>
One question I would like to ask you: Do you have knowledge how the
accuracy of the values returned is? I do understand that this will be
very driver specific, but what are your experiences? I'm especially
asking about the network error return values like the FCS counter and
alike. Can you usually trust it or do most drivers return simply 0 (or
other bogus values) each and every time?
It's impossible to say for every card, because it depends on the
implementation of NIC driver.
Regarding specific cases, I'm almost sure that Intel cards return
"reliable" values, because my guess is that they take them from the
board in the same way they do in ethtool under Linux.
Regards, ULFL
P.S: Do you know if there is an estimation of the WinPcap 3.1 release date?
We're essentially waiting for libpcap 0.9.
Loris
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev