Wrapped portmap problem on Tru64 5.0

From: Dawn Lovell <dlovell_at_centurytel.net>
Date: Thu, 12 Apr 2001 13:51:13 -0500 (CDT)

I have a very strange problem, at least to me. :-) My system is a
DS10, 512MB RAM, Tru64 5.0, patch kit 2, portmap_4.

I've been having problems with portmap dying or hanging (does both)
on one of my company's internal web servers. This server mounts some
of its data from another machine, so it's running portmap, rpc.statd,
etc. I'm running Wietse Venema's replacement portmapper, with access
restricted to only the NFS server (and localhost).

Portmap hasn't been logging anything when it dies, so I left a trace
(alpha-trace) process running to monitor the process. When it died
the next time, the output appeared to show a user's machine sending a
Windows 98 update request to the portmap daemon.

I'm not at all certain that I'm reading the output properly, so I'm
including an abbreviated version:

Tracing process /proc/108668
1 [ , {}, {}, {}, ]
[108668]: accept (4, 0x11fff99a0, 0x11fff9998=16) = 5 [ , <2/INET, 63497, 10.1.3.144>, 16 ]
[108668]: getsockname (5, 0x11fff9958, 0x11fff9950=16) = 0 [ , <2/INET, 111, 10.4.10.3>, 16 ]
[108668]: select (4096, 0x11fff9fa8={0x00000038,...
[108668]: select (4096, 0x11fff5888={0x00000020,...
[108668]: read (5, 0x40004990, 400) = 255 [, "GET http://windowsupdate.microsoft
.com/x86/W98/en/ie5//cucif.cab HTTP/1.0\r\nAccept: */*\r\nAccept-Encoding: gzip,
 deflate\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)\r
\nHost: windowsupdate.microsoft.com\r\nProxy-Connection: Keep-Alive\r\n\r\n", ]
[108668]: write (5, <80 00 00 18 ...
[108668]: select (4096, 0x11fff5958={0x00000020,...
[108668]: select (4096, 0x11fff9fa8={0x00000038,...
[108668]: select (4096, 0x11fff5938={0x00000020,...
[108668]: read (5, 0x40004993, 397) = -1 (Connection reset by peer)
[108668]: select (4096, 0x11fff58a8={0x00000020,0x00000000,...
[108668]: read (5, 0x40004993, 397) = 0 [, "", ]
[108668]: write (5, <80 00 00 18 00 00 00 01 ...
  ...00 ef ff ff ff ff ff ff ff>..., 28) = -1, (Broken pipe)
[108668]: SIGNAL [13 SIGPIPE]
[108668]: EXIT [signal=13]

I've recorded similar output when the portmap process hangs instead
of dying:

[226751]: accept (4, 0x11fff99a0, 0x11fff9998=16) = 5 [ , <2/INET, 4874, 10.1.2.2>, 16 ]
[226751]: getsockname (5, 0x11fff9958, 0x11fff9950=16) = 0 [ , <2/INET, 111, 10.4.10.3>, 16 ]
[226751]: select (4096, 0x11fff9fa8={0x00000038,...
[226751]: accept (4, 0x11fff99a0, 0x11fff9998=16) = 6 [ , <2/INET, 4340, 10.1.2.2>, 16 ]
[226751]: getsockname (6, 0x11fff9958, 0x11fff9950=16) = 0 [ , <2/INET, 111, 10.4.10.3>, 16 ]
[226751]: select (4096, 0x11fff5888={0x00000020,0x00000000,0x00000000,...
[226751]: read (5, 0x40004990, 400) = 109 [, "GET http://ctnews.creative.com/push20/dsm.dll HTTP/1.0\r\nUser-Agent: My session\r\n"..., ]
[226751]: write (5, <80 00 00 18 ...
[226751]: select (4096, 0x11fff5958={0x00000020,0x00000000,...
(hangs after several more selects)

If I do a netstat while portmap is hung, I see this:

beorn:$ netstat -na | grep 10.4.10.3.111
tcp 0 0 10.4.10.3.111 10.1.2.2.4196 ESTABLISHED
tcp 255 0 10.4.10.3.111 10.1.2.2.4630 ESTABLISHED
tcp 0 0 10.4.10.3.111 10.1.2.2.4932 ESTABLISHED
tcp 109 0 10.4.10.3.111 10.1.2.2.5350 ESTABLISHED

After killing portmap, the connections stay in FIN_WAIT_1 for a while,
then go away.

Does anyone have ideas as to why this is killing/hanging portmap and/or
why this would be bouncing off port 111 on one of our web servers? I'm
also curious how it is that the user's connection isn't being rejected
by the wrappers. When I try hitting portmap (rpcinfo -p) from a machine
not in the access lists, it does reject my connection and log the attempt.
These strange connections aren't logged at all.

Thank you for your help! Please tell me it's something obvious that I
should've seen immediately. :-)

Dawn Lovell
dlovell_at_centurytel.net
Received on Thu Apr 12 2001 - 18:51:50 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT