Harald Barth wrote: > I found another issue that might be related. This happens when the client > changes IP addr and the server kind of "does not seem to get it". > > Versions: Client 1.4.0-rc5. Server 1.4.0-rc7. > > IPs: Client changes from 130.237.237.21 to 130.237.221.63 > Server 130.237.232.199 > > Capture file: /afs/pdc.kth.se/home/h/haba/Public/openafs27-switchover.cap > Contains only rx between the hosts in question and icmp.type==unreachable. > > If you look at frame 1-5 everything works at 130.237.237.21 (home). > When I have moved my laptop it does a get-time from 130.237.232.63 > (work), see frame 26. > > During my absence from the net the server does a lot of probeuuid > which of course yield in ICMP host unreachable. The stupid thing now > is that the server and the client seem not to be able to establish the > fact that 130.237.237.21 -> 130.237.221.63 in a reasonable amount of > time. The first thing I did after reconnecting to the net is getting a > new token and some "ls" in different dirs. Client behaviour towards > the user was first a "Connection timed out" message and later hangs > which are just long enough to annoy me. > > I see a probe-uuid in frame 32 and what looks like a broken answer in > frame 33. Is that the reason why the server stubbornly sends packets > to 130.237.237.21 (frames 45-56) in spite of it talking to > 130.237.221.63 at the same time? I'd love to see some comments if this > is "normal" behaviour for this situation. > > If someone took the time to explain to me how a IP addr change of > the client is supposed to work, that would be appreciated. Especially > how to distinguish between "new interface" and "changed IP addr" on > a client interface. > > Is there any utility that can query the uuid from the client? Is there > any utility that can query the uuid to IP map from the server? > > Harald. > > PS: If using ethereal, you probably want the patch I posted previously > (or something similar).
I will try to answer the easy questions first. To obtain the UUID of a client you can use: [\\afs\asanka\Public\khimaira\bin]cmdebug localhost -addr UUID: 736f2aae-419b-4174-8472-8ecc530b52d3 Host interfaces: 192.168.1.11, netmask 255.255.255.0, MTU 1260 192.168.182.1, netmask 255.255.255.0, MTU 1260 192.168.23.1, netmask 255.255.255.0, MTU 1260 Capabilities: Error Translation At the present time there is no method that I am aware of other than examining debug log output from the file server to determine what the UUID to IP address mappings are. Onto the hard stuff. RX is supposed to be able to understand that a peer is multi-homed. As such the host structure contains a list of IP addresses and a single UUID. The fact that a peer suddenly becomes unreachable at one of the addresses in the list is not necessarily the result of the peer not using that address. It could very well be the case that routing errors in the network have made that address temporarily unreachable. The current logic only removes an IP address from a host entry if there is a positive indication that it now belongs to a new UUID. There is no logic to remove addresses that are simply not responding. There is an open ticket in RT, 3120, that is meant to deal with this. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
