Re: [WinPcap-users] WinPcap NMap

2004-04-21 Thread Gianluca Varenni

- Original Message - 
From: Gisle Vanem [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 19, 2004 9:51 PM
Subject: Re: [WinPcap-users] WinPcap  NMap


 Alan S. Jones [EMAIL PROTECTED] said:

  I have been watching some of the WinPcap 3.1 beta development along with
  NMap development.  At one point I ran into some problems with NMap after
I
  upgraded to WinPcap 3.1 beta.  Not figuring anything else out till I ran
  across some comments that made me downgrade to WinPcap 3.0 and things
  seemed to work fine.
 
  My impression from reading the WinPcap list was that programs should not
  need to make any changes to work between WinPcap 3.0 and 3.1.

 That was surely the intention of the WinPcap developers, but practice and
 implicit rules like ASCII naming are used only on Win-9x and Unicode on
 Win-NT was broken in the 3.1 update. Many programs (including nmap)
 makes this assumption.

Well, I do not think they make any assumption. They were written following
the specs of the old versions of the Packet API.

 Not really surprising since many of the WinPcap
 examples does the same thing

Well, we did modified some examples from 3.0 to 3.1beta, but these
modifications affected only the ones using the Packet API (we actually
modified some examples using the pcap API, in order to use some better pcap
APIs).


 So instead of breaking this rule, our Italian friends should IMHO have
created
 a new function that returns ASCII on Win-NT+ and a backward compatible
function
 that returns Unicode on Win-NT+. Kind of messy, but ...

That's why we sent a request for comments on August 2003. No one told us
hey, you'd better do this way. Instead, a user said

---
|  - PacketGetAdapterNames() now returns the names of the|
|  adapter in ASCII rather than in Unicode.  |
| This is quite good. |
---

and noone complained about this.


  This is the URL of the start of a thread in the NMap group about a fix
to
  get 3.1 to work:
  http://seclists.org/lists/nmap-dev/2004/Jan-Mar/0077.html

 Sounds familiar since I wrote that :) But isn't there an updated binary of
nmap
 you can use? Or compile it yourself?

Why doesn't nmap migrate to the pcap API, instead of using the packet API?



 BTW. There are other problems with pcap_open_live() in 3.1; If you
 pass a device on a machine with = 2 devices (in my case the RealTek
 eth adapter and the IPv6 pseudo tunnelling device), the
PacketOpenAdapter()
 will fail since (OTOH) the list of *all* devices hasn't been found at that
point
 (since PacketGetAdapterNames() and  PacketPopulateAdaptersInfoList()
 hasn't been called).

 An easy fix is to do (void) pcap_lookupdev(errbuf) (or
pcap_findalldevs*())
 before pcap_open_live() on the device you want to use.

I have fixed this problem on our source tree. Why didn't you report this
problem on the winpcap-bugs mailing list when you discovered the bug,
instead of

 --gv

 GNU GPL: Free as in herpes.



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


Re: [WinPcap-users] WinPcap NMap

2004-04-19 Thread Gianluca Varenni

- Original Message - 
From: Alan S. Jones [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, April 18, 2004 9:43 PM
Subject: [WinPcap-users] WinPcap  NMap




 I have been watching some of the WinPcap 3.1 beta development along with
 NMap development.  At one point I ran into some problems with NMap after I
 upgraded to WinPcap 3.1 beta.  Not figuring anything else out till I ran
 across some comments that made me downgrade to WinPcap 3.0 and things
 seemed to work fine.

 My impression from reading the WinPcap list was that programs should not
 need to make any changes to work between WinPcap 3.0 and 3.1.

Yes, If they use the pcapXXX API. You can have problems only if you use the
PacketXXX API. And nmap is actually using the PcapXXX API (line 308 of
winip.c in the nmap 3.50 sources). A clean solution to the problem is to use
pcap_findalldevs(), which is available on both WinPcap and libpcap from
quite a lot of time.

 Is this a bug in WinPcap?  Is the fix proposed the best fix?  It might be
 nice if the right people on each side talked if needed.

This is a bit disappointing: we sent a mail to this mailing list proposing
some changes in the PacketXXX API (clearly stating the possible breaks in
current applications) at the end of August 2003. Nobody told us hey, Nmap
will stop working!.

At the beginning of february 2004, we released WinPcap 3.1beta. This version
was the first release having these PacketXXX API modifications (they were
documented both in the announce message posted on this mailing list, and in
the WinPcap online changelog). Some users reported a problem with nmap (on
the winpcap-bugs mail address), and we advised them to contact the nmap
developers.

I think we did our best to help our users. There are tons of apps based on
winpcap, we cannot contact their authors one by one telling them hey, have
you tested your app with the newest winpcap? Does it work for you? or
something like that. What we do is to announce our releases (and send
request for comments) on the winpcap-users mailing.

Sorry for the long mail.

Have a nice day
GV


 This is the URL of the start of a thread in the NMap group about a fix to
 get 3.1 to work:
 http://seclists.org/lists/nmap-dev/2004/Jan-Mar/0077.html


 You can see the whole thread here:
 http://seclists.org/lists/nmap-dev/2004/Jan-Mar/

 List info:
 http://seclists.org/#nmap-dev



 --
 Alan S. Jones
 [EMAIL PROTECTED]
 http://users.ipa.net/~asj



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


Re: [WinPcap-users] WinPcap NMap

2004-04-19 Thread Gisle Vanem
Alan S. Jones [EMAIL PROTECTED] said:

 I have been watching some of the WinPcap 3.1 beta development along with
 NMap development.  At one point I ran into some problems with NMap after I
 upgraded to WinPcap 3.1 beta.  Not figuring anything else out till I ran
 across some comments that made me downgrade to WinPcap 3.0 and things
 seemed to work fine.
 
 My impression from reading the WinPcap list was that programs should not
 need to make any changes to work between WinPcap 3.0 and 3.1.

That was surely the intention of the WinPcap developers, but practice and
implicit rules like ASCII naming are used only on Win-9x and Unicode on
Win-NT was broken in the 3.1 update. Many programs (including nmap)
makes this assumption. Not really surprising since many of the WinPcap
examples does the same thing

So instead of breaking this rule, our Italian friends should IMHO have created
a new function that returns ASCII on Win-NT+ and a backward compatible function
that returns Unicode on Win-NT+. Kind of messy, but ...

 This is the URL of the start of a thread in the NMap group about a fix to
 get 3.1 to work:
 http://seclists.org/lists/nmap-dev/2004/Jan-Mar/0077.html

Sounds familiar since I wrote that :) But isn't there an updated binary of nmap
you can use? Or compile it yourself?

BTW. There are other problems with pcap_open_live() in 3.1; If you
pass a device on a machine with = 2 devices (in my case the RealTek 
eth adapter and the IPv6 pseudo tunnelling device), the PacketOpenAdapter() 
will fail since (OTOH) the list of *all* devices hasn't been found at that point 
(since PacketGetAdapterNames() and  PacketPopulateAdaptersInfoList()
hasn't been called).

An easy fix is to do (void) pcap_lookupdev(errbuf) (or pcap_findalldevs*()) 
before pcap_open_live() on the device you want to use.

--gv

GNU GPL: Free as in herpes.



==
 This is the WinPcap users list. It is archived at
 http://www.mail-archive.com/[EMAIL PROTECTED]/

 To unsubscribe use 
 mailto: [EMAIL PROTECTED]
==