Wireshark-users: Re: [Wireshark-users] Problem running Wireshark in HP UX [/dev/urandom problem]
From: Guy Harris <[email protected]>
Date: Mon, 2 Jun 2008 21:06:29 -0700
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.