inet_pton() bad family "26" on well known package

Hi,
we have a package "LPRng" that we deploy everywhere. 
The package is rather old, but works fine in all cases, except for one system.

When I attempt to do lpq on the failbox I get:

lpq
  pr99: inet_pton: bad family '26'

On an identical system, the commands work fine.

I did some reading and this has something to do with "IPv6" which we do not configure for,
but just IPv4.

I have scoped the two systems and the failbox had an IPv6 style entry for "localhost",
so I removed it but left the remaining v4 entry.   Next I rebooted the system in case something
was cached in-kernel or in the TCP/IP stack or whatever.

I checked a file on both systems:

cat /etc/inet/sock2path | grep 26
 	26      2       0       /dev/tcp6
         26      2       6       /dev/tcp6
         26      1       0       /dev/udp6
         26      1       17      /dev/udp6
         26      4       0       /dev/rawip6
         26      2       132     /dev/sctp6
         26      6       132     /dev/sctp6

And this is obviously something definitely to do with IPv6.

I have now exhausted what I know about looking for IPv6 entries on the system 
and do not know where to look next.   The /etc/inet files are the same formats on both systems, 
as is /etc/netmasks, ipnodes etc.

When I do a truss of the binary, which is identical on both systems, the failbox immediately starts 
going down a different path to the okbox.

eg - failbox:
open64("/var/run/name_service_door", O_RDONLY)  = 3
fcntl(3, F_SETFD, 0x00000001)                   = 0
door_info(3, 0xFF2858D0)                        = 0
close(3)                                        = 0
open("/etc/nsswitch.conf", O_RDONLY|O_LARGEFILE) = 3
fcntl(3, F_DUPFD, 0x00000100)                   Err#22 EINVAL
read(3, " #\n #   C o p y r i g h".., 1024)     = 1024
mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFF100000
read(3, " t h e   s y s t e m   w".., 1024)     = 273
read(3, 0xFF372400, 1024)                       = 0
close(3)                                        = 0
...


goodbox:
open64("/var/run/name_service_door", O_RDONLY)  = 3
fcntl(3, F_SETFD, 0x00000001)                   = 0
door_info(3, 0xFF233910)                        = 0
door_call(3, 0xFFBFF34C)                        = 0
getuid()                                        = 0 [0]
getuid()                                        = 0 [0]
setuid(0)                                       = 0
seteuid(0)                                      = 0
getuid()                                        = 0 [0]
getuid()                                        = 0 [0]
setuid(0)                                       = 0
seteuid(0)                                      = 0
getuid()                                        = 0 [0]
sigaction(SIGCLD, 0xFFBFF5D8, 0xFFBFF678)       = 0
....


So from the point above where the door opens, they then diverge greatly in result.


So, my analysis thus far is:
There is an IPv6 config in place somewhere on "failbox" that "okbox" does not have.

Where do I start looking now?   I have done a side by side eyeball audit of the appropriate configs and 
cannot see it.   Is it something to do with the name_service_door?

Any advice much appreciated!


rachel

-- 
Rachel Polanskis                 Kingswood, Greater Western Sydney, Australia
[email protected]                http://www.zeta.org.au/~grove/grove.html
 	The more an answer costs, the more respect it carries.