Re: [tcpdump-workers] Building libpcap 0.7.1 on MacOS X10.1.4?
At 9:51 PM -0700 2002/04/30, Guy Harris wrote: I wasn't expecting any of those changes to fix the behavior of xprobe; I was just expecting them to remove the warnings. Ahh, I see. Sorry, I misunderstood. I'd actually go for my other suggestion, with temporary bpf_u_int32 variables pointers to which are passed to pcap_lookupnet() and which are assigned to the two structure members. So, we change the cast from uint32_t to bpf_u_int32, but leave the rest of the code unchanged? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
Re: [tcpdump-workers] Building libpcap 0.7.1 on MacOS X10.1.4?
At 12:15 PM -0700 2002/05/01, Guy Harris wrote:
So, whilst the configure script will not *explicitly* define it as
anything other than an unsigned long, if it's already defined by the OS
- whether as an unsigned int, or as an unsigned long, or as
something else - it will not define it at all, so the OS's definition
will be used, and that definition might be unsigned int.
Oh. Okay. I guess I'm just demonstrating my ignorance again.
Thanks for the clarification. It is interesting to learn more
about how some of these kinds of things are handled, and what kind of
sometimes convoluted path things sometimes tend to take.
It would probably be best if the xprobe configure script used unsigned
int rather than unsigned long; unsigned int won't work on PDP-11s
or Zilog Z8000-based machines or some very old 68000-based machines or
pre-80386 PCs or other 16-bit-int platforms, but unsigned long won't
work on Alphas or IA-64s in native mode or 64-bit
{MIPS,SPARC,POWER/PowerPC,PA-RISC,...} machines, and the first set are
old platforms on which I suspect xprobe might not work anyway while the
latter set are new machines, so I'd say it'd be better to cater to those
machines rather than the older machines. (I suspect there are
OSes/compilers for those newer machines that don't define uint32_t.)
Actually, I would submit that the configure script (I'm pretty
sure it's just a very old gnu autoconf script) should be more
intelligent and automatically detect the natural word length of the
CPU it's running on, and then for types like uint32_t, it should then
select the shortest type that would fit the necessary bit length.
However, note that there is no system-supplied pcap.h.
It's often the case that a library that's supplied as a dynamic library
will include two packages:
1) a run-time package, which is installed for the benefit of
programs that *use* the library, which contains only what you
need to run those programs, i.e. the dynamic library and any
files it requires;
2) a developer's package, which is for use when you're
*compiling* programs that use the library, and which would
contain header files and perhaps non-shared libraries and the
like.
For MacOS X, the Developer's Tools are available on a separate CD
in the commercial shrink-wrap package for MacOS X (note that MacOS X
Server is a different product), and I actually do have the complete
developer's toolkit installed on this machine. I'm guessing that
this is a feature that either got accidentally omitted, or perhaps
they made a conscious decision to leave out certain header files.
But then why they'd ship a broken libpcap implementation is something
that just completely escapes me.
There isn't one on your machine, at least. I suspect there may be some
developer's package that includes it.
I've got the developer's package installed. If I didn't, then I
wouldn't have gcc.
I've no idea why
% gcc iflist.c -o iflist -lpcap
managed to find the one in /usr/local/include; perhaps GCC defaults to
looking there as well, or perhaps you have some environment variable set
causing it to search there.
IIRC, in at least some implementations, gcc does default to
looking in both /usr/lib and /usr/local/lib, as well as /usr/include
and /usr/local/include. Certainly this has been the kind of
behaviour I have come to expect from gcc in all my previous
encounters with it.
If you put -lpcap *after* iflist.c, it will be linked *after*
iflist.o, so that the libpcap functions referred to by iflist.c will
have been referred to, and the files in the libpcap library that define
those functions will be linked in, and those functions will be defined.
Right, which is what we want -- I think.
However, the resulting program still doesn't work:
% ./iflist
Error in pcap_lookupdev: no suitable device found
Preferred device is on network: 0.0.0.0/0.0.0.0
Well, that's the same problem you saw with the other programs.
Of course, it turns out that another problem was the root uid issue.
Well, that's annoying, but I guess that's another Apple improvement.
Linkers on *other* flavors of UNIX tend to use the first library found
in the library search path *even if it happens to be an archive
library*, on the grounds that the user told them to do that.
In that case, there would seem to be no way we could over-ride a
broken libpcap.dylib library, without moving it aside and generating
our own compatibly formatted dynamic library, and then store that in
/usr/lib. We need to provide functionality for future programs
(which could be statically linked), but we also need to provide
corrected functionality for existing programs (which would depend on
the dynamic library).
--
Brad Knowles, [EMAIL PROTECTED]
They that can give up
Re: [tcpdump-workers] Building libpcap 0.7.1 on MacOS X10.1.4?
At 6:56 PM -0700 2002/04/29, Guy Harris wrote:
Now, I'm not quite sure what to make of this. Did the interface
to pcap_lookupnet() change between version 0.4 and 0.7.1?
No, it didn't.
What are the types of the second and third arguments to
pcap_lookupnet() in that line of pcap_iface.c? They *should* both
be bpf_u_int32 *.
The segment of code that calls this routine says:
if (pcap_lookupnet(iname, (uint32_t *)(interf.net),
(uint32_t *)(interf.netmask), errbuf) 0) {
fprintf(stderr,pcap_lookupnet: %s\n,errbuf);
return -1;
}
Looking at the libpcap header files, it seems that pcap.h defines:
/*
* Compatibility for systems that have a bpf.h that
* predates the bpf typedefs for 64-bit support.
*/
#if BPF_RELEASE - 0 199406
typedef int bpf_int32;
typedef u_int bpf_u_int32;
#endif
But this value does not seem to be otherwise defined anywhere in
/usr/local/include/pcap*.h -- the value is used in a variety of
places, but this seems to be the only potential definition.
Does xprobe have an argument that lets you explicitly specify an
interface on which to capture?
Indeed, it does.
If so, try capturing on en0 or en1, using that argument. Does that
succeed?
Partially. Using the same definitions for lo0, en0, and en1 that
were previously posted, I get:
# xprobe -v -i lo0 127.0.0.1
X probe ver. 0.0.2
--
Interface: lo0/127.0.0.1
LOG: Target: 127.0.0.1
LOG: Netmask: 255.255.255.255
LOG: probing: 127.0.0.1
LOG: [send]- UDP to 127.0.0.1:32132
LOG: [98 bytes] sent, waiting for response.
TREE: IP total length field value is OK
TREE: Frag bits are OK
LOG: [send]- ICMP echo request to 127.0.0.1
LOG: [68 bytes] sent, waiting for response.
TREE: ICMP code !=0
TREE: DF bit in icmp echo response is echoed
LOG: [send]- ICMP information request to 127.0.0.1
LOG: [68 bytes] sent, waiting for response.
Receive timeout. Quitting..
FINAL:[ Unknown Unix (Accuracy dropped) ]
# xprobe -v -i en1 10.0.1.12
X probe ver. 0.0.2
--
ioctl(SIOCGIFADDR): Can't assign requested address
# xprobe -v -i en1 10.0.1.1
X probe ver. 0.0.2
--
ioctl(SIOCGIFADDR): Can't assign requested address
Trying again a bit later, I get:
# xprobe -v -i lo0 127.0.0.1 Password:
X probe ver. 0.0.2
--
Interface: lo0/127.0.0.1
LOG: Target: 127.0.0.1
LOG: Netmask: 255.255.255.255
LOG: probing: 127.0.0.1
LOG: [send]- UDP to 127.0.0.1:32132
LOG: [98 bytes] sent, waiting for response.
TREE: IP total length field value is OK
TREE: Frag bits are OK
LOG: [send]- ICMP echo request to 127.0.0.1
LOG: [68 bytes] sent, waiting for response.
TREE: ICMP code !=0
TREE: DF bit in icmp echo response is echoed
LOG: [send]- ICMP information request to 127.0.0.1
LOG: [68 bytes] sent, waiting for response.
Receive timeout. Quitting..
FINAL:[ Unknown Unix (Accuracy dropped) ]
# xprobe -v -i en1 10.0.1.13
X probe ver. 0.0.2
--
Interface: en1/10.0.1.13
LOG: Target: 10.0.1.13
LOG: Netmask: 255.255.255.255
LOG: probing: 10.0.1.13
LOG: [send]- UDP to 10.0.1.13:32132
LOG: [98 bytes] sent, waiting for response.
Receive timeout. Quitting..
Error while sending UDP query. Quiting
# sudo xprobe -v -i en1 10.0.1.1
X probe ver. 0.0.2
--
Interface: en1/10.0.1.13
LOG: Target: 10.0.1.1
LOG: Netmask: 255.255.255.255
LOG: probing: 10.0.1.1
LOG: [send]- UDP to 10.0.1.1:32132
LOG: [98 bytes] sent, waiting for response.
TREE: Cisco IOS 11.x-12.x! Extreme Network Switches.Linux 2.0.x!2.2.x!2.4.x.
TREE: Cisco IOS 11.x-12x! Extreme Network Switches.
FINAL:[ Cisco IOS 11.x-12.x ]
Hmm. Maybe my failures were a result of a DHCP license that was
in the process of being dropped and renewed? Things seem to have
worked okay afterwards.
Interestingly, when comparing the performance of xprobe-0.0.2
against nmap-2.54beta30 on 10.0.1.1 (my 802.11b WLAN AP), xprobe gets
the OS wrong and nmap can't figure out what it is (trying both UDP
TCP). Trying both programs against the public interface for this
device, xprobe still gets the OS wrong but now nmap gets it right.
Scanning the local machine (via 10.0.1.13 on en1, the PowerBook G3
running MacOS X 10.1.4), xprobe simply gives up, while nmap pretty
much nails it when scanning TCP ports (FreeBSD 4.4 or MacOS X 10.0.4
(Darwin V. 1.3-1.3.7 or 4P13)).
pcap_lookupdev() will, in libpcap 0.7.1, only return an interface that
it could open with pcap_open_live().
While xprobe isn't quite working the way I would hope, I am at
least able to run the program and get some output. I suspect that
most of my problems now are related to the youth of the code and the
fact that it doesn't have a fingerprint database system, and not so
much issues with libpcap, etc
Thanks!
--
Brad Knowles, [EMAIL PROTECTED]
They that can give up essential liberty to obtain a little
Re: [tcpdump-workers] Building libpcap 0.7.1 on MacOS X10.1.4?
At 2:10 AM -0700 2002/04/30, Fyodor wrote: I am glad Nmap was reasonably accurate in identifying your hardware. However, a more recent version might do better -- I have added more than 100 fingerpritns since 2.54BETA30. You've updated it again? Cool. I had no idea. I'll check that out immediately. Thanks! -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
