ypbind fails to connect to NIS server on other subnet

[Steven Pringle]

Hi There,

I have two HP-UX11i v2 itanium servers which are set up as NIS clients to a Windows 2008 server acting as a NIS master and a Windows 2003 server acting as a NIS subordinate on a different subnet. If I use the ypset option to ypbind, specifing the address of the Windows 2008 server, it all works fine, but if I use the ypinit -c command to create a list of NIS servers, and start ypbind without the ypset option, ypbind fails to connect to the NIS server (the error in the log states:-
The list of NIS servers in the file /var/yp/binding/DOMAIN/ypservers is not responding. Trying to get a binding by broadcasting.
The IP address speceifed for the ypset command, and that in the ypservers file is identical.

I would prefer to use the ypinit -c method, as I would like to specify a list of NIS servers for resiliance against failure of the master.

Any ideas what might be wrong?

[TTr]

> The list of NIS servers in the file /var/yp/binding/DOMAIN/ypservers is not responding. Trying to get a binding by broadcasting

Just to verify, you start ypbind without any options right? Check the /etc/rc.config.d/namesvrs file and ensure there are no ypbind options that may be incorrect.

Check the access time stamp (ll -u) of the /var/yp/binding/DOMAIN/ypservers file to see if ypbind even reads it. (shutdown ypbind and wait 2 minutes for the file to "age" out. Then start ypbind and check the access time of the ypservers file. It should be the same as the the time that you started ypbind. If it is not, then the file is not getting read at all. Check the permissions and spelling of the whole path /var/yp/binding/DOMAIN/ypservers

[Dave Olker]

What are the contents of the /var/yp/binding/DOMAIN/ypservers file?

Dave

[Steven Pringle]

Hi,

Many Thanks for the replies.
TTr,
I've checked the namesvrs config file, and there are no options being applied to ypbind.
The timestamp on the ypservers file does get updated to the time that I start ypbind, so presumably it is being read.

Dave,
The contents of the ypservsers file is:-
10.179.22.197
10.179.22.198

[Steven Pringle]

Hi There,

Just a bit more information, I have two Tru64 Alphaservers, two RHEL5 Proliant Servers, and an RHEL4 Proliant server all configured to use NIS from the W2008 server (10.179.22.197) and the W2003 server (10.179.22.198). They all work fine, and correctly detect the failure of the master(the W2008 server) and switch over to the subordinate(the W2003 server).

When I start ypbind with no options on the HP-UX servers, the nis.client script outputs the following:-

Starting NIS CLIENT networking
starting up the rpcbind
rpcbind already started using pid: 2102
domainname DOMAIN
starting up the Network Information Service
starting up the ypbind daemon
/usr/lib/netsvc/yp/ypbind
Checking NIS binding.
Unable to bind to NIS server using domain APMSDEV.
starting up the keyserv daemon
/usr/sbin/keyserv

if I check the binding using ypwhich, it shows that ypbind has bound to the subordinate server (10.179.22.198), and ypcat etc works.

If I force ypbind to connect to the master server using the ypset option, I get the following output from the nis.client script:-

Starting NIS CLIENT networking
starting up the rpcbind
rpcbind already started using pid: 2102
domainname DOMAIN
starting up the Network Information Service
starting up the ypbind daemon
ypbind will not use the server list available in the file /var/yp/binding//ypservers for binding purposes. Also if ypbind is invoked with the -broadcast option, then -broadcast option is ignored.
/usr/lib/netsvc/yp/ypbind -ypset
calling ypset with 10.179.22.197
Checking NIS binding.
Bound to NIS server using domain APMSDEV.
starting up the keyserv daemon
/usr/sbin/keyserv

If I check the binding using ypwhich, it shows that ypbind has correctly bound to the Master server (10.179.22.197)and ypcat etc works OK.

If I start ypbind with a just a -v option, I get the following output from the nis.client script:-
Starting NIS CLIENT networking
starting up the rpcbind
rpcbind already started using pid: 2102
domainname DOMAIN
starting up the Network Information Service
starting up the ypbind daemon
running verbose (for debugging)
10.179.22.197: RPC :Timed out
sockaddr_in.sin_family 2
sockaddr_in.sin_port 740
sockaddr_in.sin_addr 0
version is 2
10.179.22.197: RPC :Timed out
10.179.22.198: RPC :Program/version mismatch; low version = 2, high version = 2 we do hav a old version bound
NIS: server not responding

At this point the nis.client script hangs and I get no further output. ypwhich shows that ypbind is bound to the subordinate server 10.179.22.198, this also triggers further output from the nis.client script:-
sockaddr_in.sin_family 2
sockaddr_in.sin_port 740
sockaddr_in.sin_addr 0
version is 2

Not sure if any of this helps or not.

[Dave Olker]

Not sure why the automated binding to that IP address is failing and the manual one works. Only thing I can think of to try at the moment is collect a network trace of the manual (working) ypset command forcing the binding and then collect a 2nd network trace of the failing (automated) ypbind startup where it can't bind to the IP address and then compare the traces to see if there's something visible in the failing trace to explain what's different from the working trace.

Regards,

Dave

[TTr]

> 10.179.22.197: RPC :Timed out
> 10.179.22.198: RPC :Program/version...

It does seem that it may be using different connection parameters each time and when using the ypservers file the NIS master rpc may be timing out. I was thinking about a network trace as well. You can install tcpdump from the internetExpress suite https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1123

In addition to the network trace you can also run ypbind through tusc to see what it is doing in each case.
You can also turn on dedicated logging for ypbing by enabling the "-l" option in the /etc/rc.config.d/namesvrs file. If you use ypset mode or the "-v" option you put all options together as in
YPBIND_OPTIONS="-v -l /var/yp/ypbind.log -ypset"
And finally check if there is anything in the logs on the server side regrding the connection in each case.

[Steven Pringle]

Hi Dave, TTr,

Many thanks fo the replies.

Here is the content of the tcpdump for ypbind with no parameters:-


09:14:42.381269 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 106: ebu015.49847 > EBK001.portmap: UDP, length 64
0x0000: 4500 005c bd31 4000 4011 3a4e 0ab3 16e7
0x0010: 0ab3 16c5 c2b7 006f 0048 0086 4ab9 bb2d
0x0020: 0000 0000 0000 0002 0001 86a0 0000 0003
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0001 86a4 0000 0002 0000 0003
0x0050: 7564
09:14:42.419634 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 86: EBK001.portmap > ebu015.49847: UDP, length 44
0x0000: 4500 0048 6082 4000 7f11 5811 0ab3 16c5
0x0010: 0ab3 16e7 006f c2b7 0034 973a 4ab9 bb2d
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 000d 302e 302e 302e 302e
0x0040: 332e 3137 3700 0000
09:14:42.419688 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 106: ebu015.49850 > EBK001.portmap: UDP, length 64
0x0000: 4500 005c bd32 4000 4011 3a4d 0ab3 16e7
0x0010: 0ab3 16c5 c2ba 006f 0048 049c 4ab9 b715
0x0020: 0000 0000 0000 0002 0001 86a0 0000 0003
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0001 86a4 0000 0001 0000 0003
0x0050: 7564
09:14:42.419747 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 86: EBK001.portmap > ebu015.49850: UDP, length 44
0x0000: 4500 0048 6083 4000 7f11 5810 0ab3 16c5
0x0010: 0ab3 16e7 006f c2ba 0034 9b4f 4ab9 b715
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 000d 302e 302e 302e 302e
0x0040: 332e 3137 3700 0000

Here is the tcpdump output from ypbind started with the -ypset option:-
09:16:54.000518 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 98: ebu015.796 > EBK001.portmap: UDP, length 56
0x0000: 4500 0054 bd33 4000 4011 3a54 0ab3 16e7
0x0010: 0ab3 16c5 031c 006f 0040 f42d 4abc 6c86
0x0020: 0000 0000 0000 0002 0001 86a0 0000 0002
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0001 86a4 0000 0002 0000 0011
0x0050: 0000
09:16:54.008085 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 70: EBK001.portmap > ebu015.796: UDP, length 28
0x0000: 4500 0038 6d77 4000 7f11 4b2c 0ab3 16c5
0x0010: 0ab3 16e7 006f 031c 0024 fe14 4abc 6c86
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 03b1
09:16:54.008139 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 94: ebu015.797 > EBK001.945: UDP, length 52
0x0000: 4500 0050 bd34 4000 4011 3a57 0ab3 16e7
0x0010: 0ab3 16c5 031d 03b1 003c 521f 4abc 6920
0x0020: 0000 0000 0000 0002 0001 86a4 0000 0002
0x0030: 0000 0001 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0000 0007 4150 4d53 4445 5600
09:16:54.008197 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 70: EBK001.945 > ebu015.797: UDP, length 28
0x0000: 4500 0038 6d78 4000 7f11 4b2b 0ab3 16c5
0x0010: 0ab3 16e7 03b1 031d 0024 01e8 4abc 6920
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 0001
09:16:58.948311 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 118: ebu015.808 > EBK001.945: UDP, length 76
0x0000: 4500 0068 bd35 4000 4011 3a3e 0ab3 16e7
0x0010: 0ab3 16c5 0328 03b1 0054 ceb0 4ab2 1aa7
0x0020: 0000 0000 0000 0002 0001 86a4 0000 0002
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0000 0007 4150 4d53 4445 5600
0x0050: 0000
09:16:58.963604 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 122: EBK001.945 > ebu015.808: UDP, length 80
0x0000: 4500 006c 6eb6 4000 7f11 49b9 0ab3 16c5
0x0010: 0ab3 16e7 03b1 0328 0058 bc93 4ab2 1aa7
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 0001 0000 0030 756e 6974
0x0040: 373a 6479 5071 4b6e 502f 3242 7a6e 593a
0x0050: 3530

The initial message sent to query the portmapper on the NIS server seems to be different depending on whether the ypset option is used or not. This seems to be the crux of the problem.

I have now done more tests on my other systems, and it appears that I was mistaken in my assupmtion that the Linux systems were working correctly. The two Tru64 systems work fine. The Linux systems behave like the HP-UX systems i.e. If I have no options specified to ypbind, and have a list of servers specified, ypbind only binds to the Windows 2003 NIS server. If I use ypset, I can get ypbind to bind o either of the NS servers.

I'm not sure whether this is a problem with the Windows 2008 NIS server, or the implementation of ypbind on Linux and HP-UX.

The fact that the initiating messages to the port mapper from ypbind are different depending on whether ypbind is started with
ypset or not suggests a problem with ypbind on the Linux and HP-UX platforms.

[Steven Pringle]

My apologies for the confusion.

I have carried out further tests on the Linux systems, and it appears they are working correctly, they are just selecting the subordinate NIS server in preference to the master NIS server, presuambly because it is faster?

If I remove the subordinate server from the list of NIS servers, so that it just contains the master, the Linux servers correctly bind to the master.

Having examined the packets issued by both Tru64 and Linux using tcpdump, it appears that the first message that gets sent to the NIS server is a get port prog "yp" V2 request as below:-

13:26:40.612535 00:0b:cd:dc:35:b1 > 00:09:0f:09:00:03, ethertype IPv4 (0x0800), length 98: IP ebu010.1006 > EBK001.sunrpc: UDP, length 56
0x0000: 4500 0054 0000 4000 4011 f781 0ab3 16ed E..T..@.@.......
0x0010: 0ab3 16c5 03ee 006f 0040 4369 4c23 72c2 .......o.@CiL#r.
0x0020: 0000 0000 0000 0002 0001 86a0 0000 0002 ................
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0001 86a4 0000 0002 0000 0011 ................
0x0050: 0000 0000 ....
13:26:40.613119 00:09:0f:09:00:03 > 00:0b:cd:dc:35:b1, ethertype IPv4 (0x0800), length 70: IP EBK001.sunrpc > ebu010.1006: UDP, length 28
0x0000: 4500 0038 1b7c 4000 7f11 9d21 0ab3 16c5 E..8.|@....!....
0x0010: 0ab3 16ed 006f 03ee 0024 f558 4c23 72c2 .....o...$.XL#r.
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 03f2 ........
13:26:40.614037 00:0b:cd:dc:35:b1 > 00:09:0f:09:00:03, ethertype IPv4 (0x0800), length 154: IP ebu010.48504 > EBK001.1010: UDP, length 112
0x0000: 4500 008c 0000 4000 4011 f749 0ab3 16ed E.....@.@..I....
0x0010: 0ab3 16c5 bd78 03f2 0078 43a1 868c bc4a .....x...xC....J
0x0020: 0000 0000 0000 0002 0001 86a4 0000 0002 ................
0x0030: 0000 0002 0000 0001 0000 003c 4abc b700 ........... 0x0040: 0000 0006 6562 7530 3130 0000 0000 0000 ....ebu010......
0x0050: 0000 0000 0000 ......
13:26:40.614484 00:09:0f:09:00:03 > 00:0b:cd:dc:35:b1, ethertype IPv4 (0x0800), length 70: IP EBK001.1010 > ebu010.48504: UDP, length 28
0x0000: 4500 0038 1b7d 4000 7f11 9d20 0ab3 16c5 E..8.}@.........
0x0010: 0ab3 16ed 03f2 bd78 0024 b84a 868c bc4a .......x.$.J...J
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0001 ........
13:26:40.619532 00:0b:cd:dc:35:b1 > 00:09:0f:09:00:03, ethertype IPv4 (0x0800), length 94: IP ebu010.1008 > EBK001.1010: UDP, length 52
0x0000: 4500 0050 0000 4000 4011 f785 0ab3 16ed E..P..@.@.......
0x0010: 0ab3 16c5 03f0 03f2 003c 4365 5f2b 1c46 ......... 0x0020: 0000 0000 0000 0002 0001 86a4 0000 0002 ................
0x0030: 0000 0001 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 0000 0007 4150 4d53 4445 5600 ........APMSDEV.
13:26:40.619972 00:09:0f:09:00:03 > 00:0b:cd:dc:35:b1, ethertype IPv4 (0x0800), length 70: IP EBK001.1010 > ebu010.1008: UDP, length 28
0x0000: 4500 0038 1b7e 4000 7f11 9d1f 0ab3 16c5 E..8.~@.........
0x0010: 0ab3 16ed 03f2 03f0 0024 3939 5f2b 1c46 .........$99_+.F
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0001 ........

This first packet is the same format as issued by the HP-UX ypbind when using the -ypset option, so it seems as though the HP-UX version of ypbind is doing something different to the Tru64 and HP-UX versions when started with no options and a list of NIS servers.

[TTr]

You probably have discovered a bug. If you want to have more fun, donload tusc and run the ypbind through it. You have to run the ypbing directly and not use the nis.client startup script
http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.10/

[Steven Pringle]

OK, I may be interpreting this incorrectly but here goes:-

The packet that is sent out when starting ypbind without any options on HP-UX appears to be calling the rpcbind service (program 100000) version 3 with a fuction code of 3 (getport). It is asking for the mapping for ypserv (program 100004) version 2, but the protocol seems wrong, it has a value of 3, and it should be either 17 (hex 11) for udp or 6 for tcp. The port number appears to be garbage (but gets ingored anyway).

The packet sent out when starting ypbind with the -ypset option appears to be calling the rpcbind service (program 100000) version 2 with a fuction code of 3 (getport). It is asking for the mapping for ypserv (program 100004) version 2, with a protocol value of hex 11 (udp) and a port of 0. This gets a sucesful reply.

Note that this packet is exactly the same format as that sent out by the Tru64 and Linux ypbind processes when attempting to connect to a server in the NIS server list.

I therefore think that there is some bug in the HP-UX version of ypbind which is sending out a malformed rpc request to get the port mapping for the ypserv process when it is started up without any options and is provided with a list of servers.

[Dave Olker]

Hi Steven,

Can you send me the raw tcpdump file you collected showing the bad ypbind request? Also, can you tell me which NFS/NIS patch level you're running on your 11i v2 system? I want to see if I can reproduce the problem in-house as that does seem like a bug.

Thanks,

Dave

[Steven Pringle]

Hi Dave,

We have finished for the weekend now, so I'll have to pick this up on Monday.

My interpretation of the V3 rpc getport request packet was incorrect. The protocol type in rpc v3 is now encoded as a string, which is given as 3 bytes long, and corresponds to the ascii characters "udp" In fact, I think the w2008 box responded with a correct reply in rpc v3 format with the port address of the ypserv service as a string of 13 bytes (hex d) correspondingto a string of "0.0.0.0.3.224" which is port 1010 (this agrees with the udp port address of 1010 for ypserv returned by an rpcinfo -p command on the w2008 server), but this reply seems to get ignored by the ypbind process, which just issues another rpc V3 getport request.

This interchange of messages can be seen in the first tcpdump listing I posted.

The windows 2003 server only supports rpc v2, so when it is sent a V3 rpc getport request, it replies with a version not supported error, which causes ypbind to fall back to sending an rpc v2 getport request which works OK, and so ypbind then succesfully binds to the W2003 NIS server.

[Steven Pringle]

Hi Dave,

NIS patch level is PHNE_37490 NFS patch level is PHNE_38252.

tcpdump output as follows:-

11:14:51.835711 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 106: ebu015.49221 > EBK001.portmap: UDP, length 64
0x0000: 4500 005c 6019 4000 4011 9766 0ab3 16e7
0x0010: 0ab3 16c5 c045 006f 0048 572c 4acc 66e6
0x0020: 0000 0000 0000 0002 0001 86a0 0000 0003
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0001 86a4 0000 0002 0000 0003
0x0050: 7564 7000 0000
11:14:51.876907 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 86: EBK001.portmap > ebu015.49221: UDP, length 44
0x0000: 4500 0048 0624 4000 7f11 b26f 0ab3 16c5
0x0010: 0ab3 16e7 006f c045 0034 f1e3 4acc 66e6
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 000d 302e 302e 302e 302e
0x0040: 332e 3234 3200 0000
11:14:51.876959 00:1a:4b:05:78:98 (oui Unknown) > 00:09:0f:09:00:03 (oui Unknown), ethertype IPv4 (0x0800), length 106: ebu015.49224 > EBK001.portmap: UDP, length 64
0x0000: 4500 005c 601a 4000 4011 9765 0ab3 16e7
0x0010: 0ab3 16c5 c048 006f 0048 5ded 4acc 6023
0x0020: 0000 0000 0000 0002 0001 86a0 0000 0003
0x0030: 0000 0003 0000 0000 0000 0000 0000 0000
0x0040: 0000 0000 0001 86a4 0000 0001 0000 0003
0x0050: 7564 7000 0000
11:14:51.877018 00:09:0f:09:00:03 (oui Unknown) > 00:1a:4b:05:78:98 (oui Unknown), ethertype IPv4 (0x0800), length 86: EBK001.portmap > ebu015.49224: UDP, length 44
0x0000: 4500 0048 0625 4000 7f11 b26e 0ab3 16c5
0x0010: 0ab3 16e7 006f c048 0034 f8a3 4acc 6023
0x0020: 0000 0001 0000 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 000d 302e 302e 302e 302e
0x0040: 332e 3234 3200 0000


If ypbind is started with a -v option, it reports RPC timeouts, so it isn't interpreting the reply packet from the NIS server as a vailid rpc v3 reply packet.

[Dave Olker]

Can you please email me (dave.olker@hp.com) or post the raw tcpdump file here? I want to look at the raw file in Wireshark so I can look at reproducing the problem.

Thanks,

Dave

[Steven Pringle]

Hi Dave,

Wireshark capture file sent to you via e-mail.

[Dave Olker]

Hi Steven,

Sorry this has taken me so long. I've been tied up in other escalations and it took me a while to configure Win2k8 systems and HP-UX systems on different subnets, etc.

I did reproduce your problem in house. When I compare the failing trace (Windows 2008 NIS server) against a working trace (11i v3 NIS server) I think I see the difference.

Here's the exchange from the Windows 2008 NIS server:

No. Time Source Destination Protocol Info
4159 31.382125 15.23.137.250 15.43.213.235 Portmap V3 GETADDR Call (Reply In 4160)
Portmap
[Program Version: 3]
[V3 Procedure: GETADDR (3)]
RPCB
Program: YPSERV (100004)
Version: 2
Network Id: udp
length: 3
contents: udp
fill bytes: opaque data
Universal Address:
length: 0
contents:
Owner of this Service:
length: 0
contents:

No. Time Source Destination Protocol Info
4160 31.382529 15.43.213.235 15.23.137.250 Portmap V3 GETADDR Reply (Call In 4159)
Portmap
[Program Version: 3]
[V3 Procedure: GETADDR (3)]
Universal Address: 0.0.0.0.2.89
length: 12
contents: 0.0.0.0.2.89


You can see the Universal Address returned by the Windows 2008 server indicates the NIS server is using IP address "0.0.0.0" and port number 601 (converted from 2.89). This response confuses the HP-UX server because it's expecting the Universal Address to contain a valid IP address. This is why it never binds to the server via direct communication and only binds to the Win2k8 box via UDP broadcasts - which don't work when the server is on a different subnet.

By contrast, here is the exchange when using an HP-UX 11i v3 NIS server:

No. Time Source Destination Protocol Info
360 4.485842 15.43.209.141 15.3.104.152 Portmap V3 GETADDR Call (Reply In 361)
Portmap
[Program Version: 3]
[V3 Procedure: GETADDR (3)]
RPCB
Program: YPSERV (100004)
Version: 2
Network Id: udp
length: 3
contents: udp
fill bytes: opaque data
Universal Address:
length: 0
contents:
Owner of this Service:
length: 0
contents:

No. Time Source Destination Protocol Info
361 4.486694 15.3.104.152 15.43.209.141 Portmap V3 GETADDR Reply (Call In 360)
Portmap
[Program Version: 3]
[V3 Procedure: GETADDR (3)]
Universal Address: 15.3.104.152.2.182
length: 18
contents: 15.3.104.152.2.182
fill bytes: opaque data


The Universal Address returned by the HP-UX server indicates the NIS server is running on IP address "15.3.104.152" and port number 694 (converted from 2.182). The 11i v3 NIS client immediately connects to the NIS server at that IP address / port number and binds successfully. So it appears the underlying difference here is the Universal Address returned by the NIS server.

I think this is something you should discuss with Microsoft and have them look at changing their NIS server code to return the correct Universal Address - one that includes both the IP address and the port number.

Regards,

Dave

[Dave Olker]

testing...