Closed infrastation closed 8 years ago
OK, so Solaris 11, as far as I know, has BPF. Is there a bpf.h anywhere under /usr/include on the SPARC host? Perhaps either there's something wrong or incomplete with the Solaris installation on that host, or it's running a different version of Solaris 11 which moved the bpf.h header somewhere else.
On SPARC:
/usr/include/pcap/bpf.h
/opt/csw/include/pcap/bpf.h
On x86:
/usr/include/pcap/bpf.h
/usr/include/net/bpf.h
/opt/csw/include/pcap/bpf.h
Are they running the same version of Solaris 11? What happens if you run man bpf
on both of them?
SunOS unstable11x 5.11 11.2 i86pc i386 i86pc
SunOS unstable11s 5.11 11.2 sun4u sparc SUNW,SPARC-Enterprise
"bpf - Berkeley Packet Filter raw network interface" from bpf(7D) on x86; no such man page on SPARC.
Is the system/network/bpf
package installed on both machines? (See the Oracle® Solaris 11.2 Package Group Lists document.)
What does ls -ld /dev/bpf*
print on both machines?
x86:
> pkg list system/network/bpf
NAME (PUBLISHER) VERSION IFO
system/network/bpf 0.5.11-0.175.2.8.0.1.2 i--
> ls -ld /dev/bpf*
lrwxrwxrwx 1 root root 27 Aug 28 11:03 /dev/bpf -> ../devices/pseudo/bpf@0:bpf
> ls -l /devices/pseudo/bpf*
crw-rw-rw- 1 root sys 53, 0 Aug 28 16:20 /devices/pseudo/bpf@0:bpf
/devices/pseudo/bpf@0:
total 0
SPARC:
> pkg list system/network/bpf
pkg list: No packages matching 'system/network/bpf' installed
> ls -ld /dev/bpf*
crw-rw-rw- 1 root sys 16, 0 Jan 22 2015 /dev/bpf
Device major numbers are different, not sure if that matters. Is the package the only way to compile libpcap in Solaris?
Well, that's weird. On the system with the package installed, the /dev/bpf
device is a symlink to an item in the /devices
tree, which I think is what most entries in /dev
are on Solaris; on the other system, it's a character special file directly planted in the /dev
directory.
Major device numbers are, I think, assigned dynamically, so I'm not sure that's an issue.
Is there a version of tcpdump installed, and what happens if you try to run it? There's a diagnostic/tcpdump
package; is it installed on either of the machines? If not, can you install it on whatever machines don't have it installed, and try it?
If you can't get the tcpdump package installed, is there a libpcap shared library on the system in a system library directory? If so, what happens if you try to build one of the libpcap test programs, such as opentest.c
, and run it?
x86:
> pkg list | grep tcpdump
diagnostic/tcpdump 4.7.4-0.175.2.12.0.4.0 i--
> tcpdump -h
tcpdump version 4.7.4
libpcap version 1.5.1
[...]
> tcpdump -D
>
> make opentest
> ./opentest
opentest: (null): You don't have permission to capture on that device ((cannot open device) /dev/bpf: Permission denied)
SPARC:
> pkg list | grep tcpdump
diagnostic/tcpdump 4.5.1-0.175.2.0.0.42.1 i--
> tcpdump -h
tcpdump version 4.5.1
libpcap version 1.5.1
[...]
> tcpdump -D
>
> gcc -D_U_="" -o opentest opentest.c -lpcap
> ./opentest
opentest: (null): You don't have permission to capture on that device ((cannot open device) /dev/bpf: Permission denied)
Looks like I am hitting the limits of a user account.
Same OS version, different versions of diagnostic/tcpdump
? That's, umm, interesting.
Can you run either tcpdump or opentest as root? (opentest takes a -i
flag to specify the interface to open. I should probably tweak it to pick a default if none was explicitly specified. I guess Sun^WOracle decided that, as everybody else's printf prints "(null)" for null-pointer arguments to %s, they should do the same thing, rather than dumping core as they used to do, legitimate though dumping core might be.)
I can only yield to @dago to obtain that additional diagnostics on those hosts.
I.e., this is happening on one of the OpenCSW build farm hosts, other than the ones doing the regular buildbot (Solaris 10) builds? If so, I'll ask Dagobert what's going on.
Yes, exactly.
I think the difference originates from the fact that unstable11s
is a zone whereas unstable11x
is the global instance. This is necessary for us as zones are the way to virtualize Sparc while we use plain VMware for x86.
The major numbers does not really matter as long as it is consistent across your horizon (usually "system", but may be "within cluster" when using NFS).
Hi I'm a college from @dago and checked the problem. The bpf package was not installed on the unstable11s zone. Did this know. So you have /usr/include/net/bpf.h now. The difference for /dev/bpf is that unstable11s is a zone and unstable11x is not. Anyway please check is it works now for you
Let me confirm libpcap now builds OK on the server. Thank you.
/usr/include/net/bpf.h
exists on the x86 host but does not exist on the SPARC host. No idea if this is a problem with the host itself, but in this case it would be better to detect the missing header at theconfigure
phase.With default compiler (gcc):
With Sun Studio compiler: