hi guys,
can anyone tell what is wrong with "Lost contact with file server " issue?
that afs clinet is not in the same domain of afs server. the connection
speed is up to 16MB/sec.
my afs server is Scientific Linux SL release 5.0 x86_64 2.6.18-53.1.6.el5 #1
SMP. i use openafs-server-1.4.6-58.SL5.
hi guys,
can anyone tell what is wrong with "Lost contact with file server " issue?
that afs clinet is not in the same domain of afs server. the connection
speed is up to 16MB/sec.
my afs server is Scientific Linux SL release 5.0 x86_64 2.6.18-53.1.6.el5 #1
SMP. i use openafs-server-1.4.6-58.SL5.
TIARA System Man wrote:
> hi guys,
>
> can anyone tell what is wrong with "Lost contact with file server "
> issue? that afs clinet is not in the same domain of afs server. the
> connection speed is up to 16MB/sec.
>
> my afs server is Scientific Linux SL release 5.0 x86_64
> 2.6.18-53.1.6.el5 #1 S
TIARA System Man wrote:
hi guys,
can anyone tell what is wrong with "Lost contact with file server "
issue? that afs clinet is not in the same domain of afs server. the
connection speed is up to 16MB/sec.
Sounds like NAT bouncing to me. The NAT device keeps timing out the
port mappings and
Jeffrey Altman <[EMAIL PROTECTED]> writes:
> This was fixed in the Windows cache manager by always retrying RPCs
> sent on an existing RX connection that timed out once with a new RX
> connection. I am not sure that a similar change was ever made to the
> UNIX cache manager.
For the record, it s
hi jeffrey,
you are right! it looks like that.
we have three branch offices. one of them is behind NAT. the other two sites
do not encounter this problem, so far. that two sites have real ip
addresses.
(snip)
This was fixed in the Windows cache manager by always retrying RPCs sent on
an existing
On Fri, Apr 18, 2008 at 8:23 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Jeffrey Altman <[EMAIL PROTECTED]> writes:
>
> > This was fixed in the Windows cache manager by always retrying RPCs
> > sent on an existing RX connection that timed out once with a new RX
> > connection. I am not sure t
> the other thing, NAT server itself also has "Lost contact" problem.
>
> please give me some hints. thank you.
>
Expire your NAT udp port mappings less aggressively?
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailma
Derrick Brashear wrote:
the other thing, NAT server itself also has "Lost contact" problem.
please give me some hints. thank you.
Expire your NAT udp port mappings less aggressively?
NAT UDP port mappings should have a lifetime of at least ten minutes.
_
hi jeffrey,
sorry. please allow me re-send it.
thank you. :)
i modified my iptables as following:
$IPTABLES -A udp_packets -p UDP -s $ALLOW_IP --sport $CLIENT_AFS_PORT
--dport 1024:65535 -j allowed -m conntrack --ctexpire 600
$IPTABLES -A udp_packets -p UDP -s $ALLOW_IP --sport 1024:65535 -
hi jeffrey,
thank you. :)
i modified my iptables as following:
$IPTABLES -A udp_packets -p UDP -s $ALLOW_IP --sport
$CLIENT_AFS_PORT --dport 1024:65535 -j allowed -m conntrack --ctexpire 600
$IPTABLES -A udp_packets -p UDP -s $ALLOW_IP --sport 1024:65535
--dport $AFS_PORT -j allowed -m
See if there is any logging you can use to determine why the mappings
are being dropped (if they are).
Perhaps the clients are in fact not reachable for some other reason.
We need more precise details.
Sam Tseng wrote:
hi jeffrey,
thank you. :)
i modified my iptables as following:
$IPTA
12 matches
Mail list logo