Vista slow RPC service

[sealnose]

Hello All,

I have a small python listener agent and requestor script, which is part of the Python demo. You start up the listener with a port to listen on, and thereafter you can send it a request, i.e. you give it two numbers to add and it returns the sum.

With a linux listener on one machine and linux requestor on another, I get the response immediately.

With a Vista listener, I get the response immediately if I request it on the same machine, but not from the other machine on the network. Linux requestor to Vista listener takes ~ 5 seconds or more.

When I sniff the network, I can see that the listener acknowledges the requestor within a second. Then it sits there for 5 more seconds, then completes the transaction. I can't see any evidence of a name resolution problem on the sniffer. Netbios has been disabled at the network configuration tool in the control panel. The NetBT service is running, but I don't see any evidence on the sniffer that it is making any requests. In any case, I'm using IP numbers not names.

So it seems to be very slow, but only when there is a network between the listener and requestor. The ping time between them is 1.7 ms, using the name.

I don't know where to look. Any suggestions?

Thanks in advance.

[cluberti]

Is this only a Vista problem, or can you repro it on a stock XP SP3 install, say? Also, are you sure you have no firewalls or antivirus sitting as LSPs on the network stack that would slow the traffic down? If LRPC works immediately, then RPC is working fine, and something on the network layer is responsible for the delay (but what that could be, hard to say right now).

[sealnose]

Thanks, cluberti, for the fast response.

I haven't tried it with XP SP3. I'm sure I don't have an antivirus or firewall. No AV was installed.

It's a brand new install and the Security Center is all red bars and warnings. I can ping it, telnet to it, and rdp into it.

Netstat says it's listening on 9090. Both the RPC service and the Locater service are enabled/automatic/started, running as local services.

Windows defender is disabled.

I tried rebooting the Vista machine.

However, this is interesting: I tried using a W2K08 machine instead of linux as a client and it worked fine.

So, linux--->linux is fine, W2K08--> Vista is fine, linux-->Vista is slow.

[cluberti]

When you get a network trace of the traffic from W2K8 -> Vista vs Linux -> Vista, are the connect packets and other traffic sending the same? It sounds like the Linux box might be doing something or sending something in the headers that the Vista box doesn't necessarily like or maybe expect?

[sealnose]

Thanks, cluberti,

I looked at the Python versions. Once I had them all at v2.6, I found that I no longer had any problems interworking between Vista and Windows 2K08.

Also, an RPC client on Ubuntu 2.8, Python 2.6 worked with the Vista RPC listener, Python 2.6.

However, a Fedora FC8, Python 2.6 would not work against the same Vista RPC listener.

I captured the network traffic for both. For the first 8 relevant frames, everything looks identical. Then, on the 9th and 10th frames, the Vista machine sends two identical multicast packets to 224.0.0.252, about a tenth of a second apart. Wireshark calls them llmnr packets, Link Local Multicast Name Resolution. There is never any response to them, and Vista apparently waits 5 seconds for an answer before carrying on. W2K08 doesn't do this. I tried putting the info for all hosts involved in Vista's LMHOSTS - no improvement. I tried disabling Vista's "Network Discovery" services, which for some reason re-enabled the firewall and stopped all networking.

Why does it need to do any name resolution? I'm using IP addresses. IPV6 and all other protocols except TCPIP V4 are is turned off in the control panel/network and sharing/manage network interfaces tool. I think if I could get Vista not to send these packets it might not wait for an answer. One of them follows below, with my IP address partially x'd out.

LNo. Time Source Destination Protocol Info

port: 60064 Destination port: llmnr

Frame 14 (86 bytes on wire, 86 bytes captured)

Arrival Time: Nov 27, 2008 11:50:19.523621000

[Time delta from previous captured frame: 0.019725000 seconds]

[Time delta from previous displayed frame: 0.019725000 seconds]

[Time since reference or first frame: 4.522034000 seconds]

Frame Number: 14

Frame Length: 86 bytes

Capture Length: 86 bytes

[Frame is marked: False]

[Protocols in frame: eth:ip:udp:data]

[Coloring Rule Name: UDP]

[Coloring Rule String: udp]

(01:00:5e:00:00:fc)

Destination: IPv4mcast_00:00:fc (01:00:5e:00:00:fc)

Address: IPv4mcast_00:00:fc (01:00:5e:00:00:fc)

st)

default)

Source: Supermic_9b:28:ce (00:30:48:9b:28:ce)

Address: Supermic_9b:28:ce (00:30:48:9b:28:ce)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory

default)

default)

Type: IP (0x0800)

.252)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 72

Identification: 0x3442 (13378)

Flags: 0x00

0... = Reserved bit: Not set

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 1

Protocol: UDP (0x11)

Header checksum: 0x460d [correct]

[Good: True]

[bad : False]

Source: xxx.xxx.xxx.14 (xxx.xxx.xxx.14)

Destination: 224.0.0.252 (224.0.0.252)

User Datagram Protocol, Src Port: 60064 (60064), Dst Port: llmnr (5355)

Source port: 60064 (60064)

Destination port: llmnr (5355)

Length: 52

Checksum: 0x19ea [correct]

[Good Checksum: True]

[bad Checksum: False]

Data (44 bytes)

Data: 916300000001000000000000023131033134330237350332...

0000 01 00 5e 00 00 fc 00 30 48 9b 28 ce 08 00 45 00 ..^....0H.(...E.

0010 00 48 34 42 00 00 01 11 46 0d cf 4b 8f 0e e0 00 .H4B....F..K....

0020 00 fc ea a0 14 eb 00 34 19 ea 91 63 00 00 00 01 .......4...c....

0030 00 00 00 00 00 00 02 31 31 03 xx xx xx xx xx xx .......11.xxx.xx

0040 xx xx xx xx 07 69 6e 2d 61 64 64 72 04 61 72 70 .xxx.in-addr.arp

0050 61 00 00 0c 00 01 a.....

^LNo. Time Source Destination Protocol Info

port: 60064 Destination port: llmnr

Thanks for your thoughts!!