[OpenAFS] Re: RPC service unavailable, windows client, udebug
Thu, 06 Nov 2014 00:18:36 +0100
Am 05.11.2014 23:57, schrieb Andrew Deason:
>> Sorry. Noticed that just after the email went out. rxdebug
>> 126.96.36.199 works just fine from the client. So now I am trying
>> tcpdump -n host 188.8.131.52 and host 184.108.40.206 and udp
>> both on the client or on the server. When I click on one of the
>> directories which reside on volumes on 220.127.116.11, I get the "RPC..
>> message " again, but I do not capture any traffic on the client. If I do
>> a "fs checkservers" on the client, I capture on the client:
> Well, you didn't see any traffic over port 7000, so that's still not
> quite helpful yet. What may be happening is that the client has already
> determined that the server was down, so it doesn't try to contact it. I
> would imagine we would try to contact the server on an 'fs
> checkservers', but maybe there is some detail of the Windows client I'm
> Do you see packets go to port 7000 while running that 'rxdebug -version'
> command? If you don't see those packets go across during that, you're
> certainly not going to see any real traffic, and you'd need to figure
> out that first.
00:05:35.557992 IP 18.104.22.168.49902 > 22.214.171.124.7000: rx
00:05:35.589045 IP 126.96.36.199.7000 > 188.8.131.52.49902: rx
> You may try just looking at those IPs and not restricting to UDP, just
> to see what traffic is going by. Or if there is too much TCP traffic,
> try excluding TCP traffic instead of including UDP traffic. If IP
> fragments are in play, you will see packets that will be identified as
> neither UDP nor TCP (but you should still see at least _one_ packet
> going to UDP port 7000, so that doesn't explain to me why you wouldn't
> see any).
windump.exe -i blah host 184.108.40.206 and host 220.127.116.11 and not tcp
gives me just an arp who-has and reply.
> Or, you can try just capturing port 7000 UDP on the client side (not
> restricted to any IP). You must see at least one packet going to port
> 7000 UDP at some point when the client is trying to access something. If
> the client ever reports the fileserver coming back up, we must have sent
> and received packets over port 7000 UDP.
windump.exe -i blah port 7000 and udp
turns up nothing when I click on directories on the "problem" fileserver
and plenty of traffic when I browse the "good" fileserver (18.104.22.168).
> Also, are you certain those are the only IPs that the client and server
> have? If they also have other IPs assigned to them, the traffic could be
> going over those.
The servers have private interfaces too, which are on a different subnet
and not connected to the rest. The fileservers have been told to ignore
these interfaces via NetInfo/NetRestrict.