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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
