http://gerrit.openafs.org/6332  removes the service name from the Firewall Rule

On 12/14/2011 10:03 AM, Anders Hannus wrote:
On the Programs and Services tab, Services, Settings..., Apply to this service: OpenAFS Client Service.
Then it doesn't work.
Changing it (back) to Apply to all programs and services. Then it works again.

Can of course be added with the netsh command as well.

I'm using this workaround now for scripted install:
netsh advfirewall firewall add rule name="AFS CacheManager Callback (UDP)" dir=in action="" enable=yes program="C:\Program Files\OpenAFS\Client\Program\afsd_service.exe" protocol=udp localport=7001


/anders hannus

-----Original Message-----
From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] On Behalf Of Jeffrey Altman
Sent: den 14 december 2011 15:16
To: openafs-info@openafs.org
Subject: Re: [OpenAFS] Re: windows openafs cache not updating

What do you mean by "add the OpenAFS Client Service to the rule"?

On 12/14/2011 7:44 AM, Anders Hannus wrote:
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="" 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:*openafs-info-ad...@openafs.org
[mailto:openafs-info-ad...@openafs.org] *On Behalf Of *Anders Hannus
*Sent:* den 13 december 2011 15:35
*To:* Jonathan Nilsson; Andrew Deason
*Cc:* openafs-info@openafs.org
*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="" 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:*openafs-info-ad...@openafs.org
[mailto:openafs-info-ad...@openafs.org] *On Behalf Of *Jonathan 
Nilsson
*Sent:* den 13 december 2011 03:28
*To:* Andrew Deason
*Cc:* openafs-info@openafs.org
*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
    adea...@sinenomine.net <mailto:adea...@sinenomine.net>

    _______________________________________________
    OpenAFS-info mailing list
    OpenAFS-info@openafs.org <mailto:OpenAFS-info@openafs.org>
    https://lists.openafs.org/mailman/listinfo/openafs-info



 

--

Jonathan.Nilsson at uci dot edu

Social Sciences Computing Services

SSPB 1265 | 949.824.1536

 

:��

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to