[OpenAFS] Re: RPC service unavailable, windows client, udebug works

Christian chanlists@googlemail.com
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
>> 130.75.103.223 works just fine from the client. So now I am trying
>>
>> tcpdump -n host 130.75.103.223 and host 130.75.102.221 and udp
>>
>> both on the client or on the server. When I click on one of the
>> directories which reside on volumes on 130.75.103.223, 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
> missing.
>
> 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 130.75.102.221.49902 > 130.75.103.223.7000:  rx
version (29)
00:05:35.589045 IP 130.75.103.223.7000 > 130.75.102.221.49902:  rx
version (93)
> 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 130.75.103.223 and host 130.75.102.221 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 (130.75.103.221).

> 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.

Thanks,

Christian