I redid the test today and the windows firewall blocks the UDP 7001 packets. Adding a new rule with:
netsh advfirewall firewall add rule name="AFS CacheManager Callback (UDP)" dir=in action=allow enable=yes program="C:\Program Files\OpenAFS\Client\Program\afsd_service.exe" opens up and the test is successful. If I add the OpanAFS Client Service to the rule it fails. /anders From: [email protected] [mailto:[email protected]] On Behalf Of Anders Hannus Sent: den 13 december 2011 15:35 To: Jonathan Nilsson; Andrew Deason Cc: [email protected] Subject: RE: [OpenAFS] Re: windows openafs cache not updating I can confirm that there seems to be an issue with the windows firewall rule and 1.7.3. Computer installed from Windows 7 Enterprise 64-bit DVD MIT Kerberos, network identity manager, Openafs 1.7.3 64-bit/32-bit tools Tried the rxdebug command from an afs server. No go. Deleted the Windows firewall rule and added a new one with netsh advfirewall firewall add rule name="AFS Callback" dir=in action=allow enable=yes protocol=udp localport=7001 And now it works. We haven't seen this this issue here with 1.7.3 as a custom firewall rule was required for 1.7.1 anyway and we haven't removed it yet. /anders Hannus Luleå technical university From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Nilsson Sent: den 13 december 2011 03:28 To: Andrew Deason Cc: [email protected] Subject: Re: [OpenAFS] Re: windows openafs cache not updating > FindClient: stillborn client 74024d60(d16fe8cc); conn 180213d0 > (host MY.CLI.ENT.IP:7001) had client f402fa30(d16fe8cc) > CB: RCallBackConnectBack (host.c) failed for host MY.CLI.ENT.IP:7001 > CB: WhoAreYou failed for host 34015890 (MY.CLI.ENT.IP:7001), error 1 > > Could these messages be indicating a problem? (They appear frequently in > the logs and I cannot tell if they correspond to specific read or write > actions on the clients.) Yes, they indicate that the fileserver cannot contact that client to tell it that the files have changed (well, the latter two, anyway). Is that client behind a NAT or some kind of stateful firewall? No, the client has a static IP. Assuming not, a simple test you can perform to check that a client is reachable from the fileserver is by running: rxdebug <client> 7001 -version doh! that does not respond. in Control Panel -> Windows Firewall -> "Allow a program or feature through Windows Firewall" it seems like the OpenAFS client must have attempted to add itself, but not completely... i see a checkbox under the "Public" network type, but not in the "Domain" or "Home/Work (Private)" network type. when I add those checkboxes, then rxdebug <client> 7001 -version works. is it intentional to only allow 7001 on Public networks but not on Domain networks? thanks for the quick reply! -- Jonathan from the fileserver. If that does not respond with the version of that client, check firewalls et al and allow port udp 7001 to the client. This is assuming, though, that the client generally stays up. It can be normal to see messages like that if the client is abruptly removed from the network or shutdown in an unclean fashion, etc. -- Andrew Deason [email protected]<mailto:[email protected]> _______________________________________________ OpenAFS-info mailing list [email protected]<mailto:[email protected]> https://lists.openafs.org/mailman/listinfo/openafs-info -- Jonathan.Nilsson at uci dot edu Social Sciences Computing Services SSPB 1265 | 949.824.1536
