Wireshark-users: Re: [Wireshark-users] Problem running Wireshark in HP UX [/dev/urandom problem]
On Jun 2, 2008, at 4:42 PM, Alain Bequer Martinez wrote:
Hi
I have installed Wireshark 1.0 into a HP UX server from the “Porting
And Archive Centre for HP-UX” distribution without success.
When I try to run Wireshark I get the following output:
.-.-.-.-.-.-
mispevd1$ /usr/local/bin/wireshark
Fatal: can't open /dev/urandom: Operation not supported
ABORT instruction (core dumped)
mispevd1$
.-.-.-.-.-.-
I have verified and the prngd daemon is working correctly but it
seems that the /dev/urandom socket can’t be read by Wireshark.
If Wireshark 1.0 can't open /dev/urandom, it just uses the time and
the PID as the seed for random() and uses that to generate random
numbers - and does *that* only if built with GLib 1.2[.x] and GTK+
1.2[.x]; otherwise, it just uses g_rand_new() and g_rand_int().
It's probably some library that's doing such a horrible job of
handling failure to open /dev/urandom. My guess is that it's either
gnutls, libgcrypt or openssl; the other libraries that the page at
http://hpux.connect.org.uk/hppd/hpux/Gtk/Applications/wireshark-1.0.0/
say Wireshark depends on don't look as if they do anything *so*
dependent on random numbers that they'd just give up and call abort()
if they couldn't get at /dev/urandom.
It looks as if libgcrypt
1) prints error messages with "Fatal:" at the beginning;
2) calls abort() after that;
3) calls log_fatal() - which does both 1) and 2) - with "can't open
{device name}: {strerror string}" if an attempt to open a device
fails, and does so in code that opens /dev/urandom;
so I suspect it's libgcrypt that's being so user-friendly here.
The offending code is in cipher/rndlinux.c; I'd be a bit nervous about
the last 5 characters of "rndlinux" except that the comment before the
open_device() routine says
Used to open the /dev/random devices (Linux, xBSD, Solaris (if it
exists)).
so I guess it isn't intended to be Linux-only.
In any case, this is *not* a Wireshark bug; it's either an HP-UX bug
or a bug in the version of libgcrypt that the HP-UX Porting and
Archive Center provide. The page at
http://software.hp.com/portal/printable/swdepot/displayProductInfo.do?productNumber=OPENSSL11I
says
Random number generation using /dev/urandom or /dev/random is faster
compared to/opt/openssl/prngd/prngd. However, prngd is automatically
used by the appropriate OpenSSL function when /dev/urandom or /dev/
random is not installed on the system. HP-UX 11i v1 users can
download /dev/random from the following location:
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=KRNG11I
The prngd server reads HP-UX commands from the prngd.conf file,
computes random numbers based on certain parameters, and writes the
computed random numbers to an HP-UX socket located in the /var/run/egd-
pool directory. OpenSSL functions can connect to and read random
numbers from this socket.
which seems to suggest that the socket prngd uses is *NOT* at /dev/
urandom, and the page at
http://docs.hp.com/en/B2355-60127/random.7.html
says
The character special files /dev/random and /dev/urandom provide an
interface to the kernel-resident random number generator, rng.
which indicates that /dev/urandom isn't a socket.
Perhaps
1) whatever version of HP-UX you're running doesn't support /dev/
urandom;
2) whatever configuration was done on libgcrypt was done under the
assumption that it *does* support /dev/urandom;
3) libgcrypt, unlike OpenSSL, doesn't fall back on the prngd server
if it can't open /dev/urandom.
