> The client you're running is quite old; even if this is an issue that
> has not been fixed in a newer version, I doubt anyone is going to be
> interested in trying to produce a patch against 1.3.81.

If this is severe enough, I'm sure the Debian maintainer will fix his
bugs. This is, after all, the version released with current Debian stable
(Sarge).

> To get the fileserver log level to 125, send it SIGTSTP four times.
> To turn debugging back off, send the fileserver SIGHUP.

I'll send the fileserver logs upon request: it is over 100kB long, so I
won't email it to the list (and won't publish an URL on the list either).
I can, however, immediately say that the fileserver log never shows the
IP of the client. Is this normal?

Here is one more thing: tcpdump of a "fs checkservers":

12:36:59.013846 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx data fs call op#1054934366 (44)
12:36:59.464163 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx data fs call op#1054934366 (44)
12:37:00.466386 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx data fs call op#1054934366 (44)
12:37:01.969722 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx data fs call op#1054934366 (44)
12:37:02.015633 IP dirac.tfy.utu.fi.afs3-fileserver > 
lagrange.tfy.utu.fi.afs3-callback:  rx abort (32)
12:37:03.473058 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx ack first 1 serial 0 reason ping (65)
12:37:04.475282 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx data fs call op#1054934366 (44)
12:37:06.473868 IP dirac.tfy.utu.fi.afs3-fileserver > 
lagrange.tfy.utu.fi.afs3-callback:  rx abort (32)
12:37:06.479729 IP lagrange.tfy.utu.fi.afs3-callback > 
dirac.tfy.utu.fi.afs3-fileserver:  rx ack first 1 serial 0 reason ping (65)     
                                                                 

> - Output of 'cmdebug <client-ip-addr>'

Produced nothing at all. (Since this, and the next, line stated
"client-ip", I assumed they should be run on the server and the last on
the client. Hope I was correct! =) )

> - Output of 'rxdebug <client-ip-addr> 7001'

Trying 130.232.104.188 (port 7001):
Free packets: 130, packet reclaims: 0, calls: 17469, used FDs: 64
not waiting for packets.
0 calls waiting for a thread
1 threads are idle
Done.


> - Output of 'rxdebug <fileserver-ip-addr>'

lagrange:~# rxdebug dirac.tfy.utu.fi
Trying 130.232.105.174 (port 7000):
Free packets: 582, packet reclaims: 81, calls: 94967, used FDs: 64
not waiting for packets.
0 calls waiting for a thread
11 threads are idle
Connection from host 130.232.104.188, port 7001, Cuid 83aaa7c0/4dff9bc,
error 19270409 serial 6,  natMTU 1444, flags pktCksum, security index 2,
server conn rxkad: level clear, flags pktCksum
  Received 0 bytes in 0 packets
  Sent 0 bytes in 0 packets
    call 0: # 182, state precall, mode: error
    call 1: # 0, state not initialized
    call 2: # 0, state not initialized
    call 3: # 0, state not initialized
Connection from host 130.232.105.162, port 7001, Cuid b06eb0e7/118cd340
  serial 1074,  natMTU 1444, security index 0, client conn
    call 0: # 537, state dally, mode: receiving, flags: receive_done
    call 1: # 0, state not initialized
    call 2: # 0, state not initialized
    call 3: # 0, state not initialized
Done.

Hope this helps, or I'll be forced to go Harald's way to 1.4.1. It just
makes maintaining a bit nastier. =(

-Juha

-- 
                 -----------------------------------------------
                | Juha Jäykkä, [EMAIL PROTECTED]                        |
                | home: http://www.utu.fi/~juolja/              |
                 -----------------------------------------------

Attachment: signature.asc
Description: PGP signature

Reply via email to