Jan Harkes wrote:

> On Tue, Feb 01, 2000 at 12:15:14PM -0800, Tom Tarka wrote:
> > I'm having this problem with the stock 2.2.12 kernel and with an ipsec 2.2.14
> > kernel,
> > RedHat 6.0, i686, coda 5.3.4, lwp 1.2
> >
> > I was under the impression that with 2.2.x kernels, the coda module
> > included in the kernel src was all that was necesseary...is this a
> > separate problem, or do I just need to update the coda module...
> ...
> > 11:55:32 Writeback message to 216.103.208.231 port 64887 on conn 1fccfa74
> ...
> > 12:08:48 Callback failed RPC2_DEAD (F) for ws 216.103.208.231, port 64887
>
> This is no kernel problem at all.
>
> Why is the venus portnumber so unusual?
> Are you going through a masquerading firewall?

bingo.

>
> The sftp side-effect transfers will not be able to get back to the
> client. The firewall only knows about the 2430->2432 outgoing
> connection, but doesn't forward the packets of the incoming sftp data
> from server port 2433 -> client port 2431.

fix?  I'm forwarding tcp and udp on 370, 2430, 2431 2432, 2433 using
ipmasqadm portfw on my firewall, but I've heard of ipmasq "getting confused"
with regards to connections coming to the outside IP address as opposed
to it's own IP address.  Or is this another issue?

The weird thing is when I connect from a machine on my internal network
(which, granted, is my ipmasq firewall and could potentially have the same issues,

but which shouldn't be actually going through the firewall) I get the same errors
(see below).  In any case, we're probably going the VPN route in the near
future, so hopefully this won't continue to be an issue, but any help/advice
would be great!

Thanks,
    t

CLIENT:
[root_at_agrippa /boot]# venus -init

Date: Tue 02/01/2000

12:50:51 /usr/coda/LOG setup for size 0x87cc7
12:50:51 /usr/coda/DATA initialized at size 0x21f31c
12:50:51 brain-wiping recoverable store
12:50:52 loading recoverable store
12:50:52 starting VSGDB scan
12:50:52        0 vsg entries in table
12:50:52        0 vsg entries on free-list
12:50:52 starting VDB scan
12:50:52        1 vol entries in table (0 MLEs)
12:50:52        0 vol entries on free-list (0 MLEs)
12:50:52 starting FSDB scan (833, 20000) (25, 75, 4)
12:50:52        0 cache files in table (0 blocks)
12:50:52        833 cache files on free-list
12:50:53 starting HDB scan
12:50:53        0 hdb entries in table
12:50:53        0 hdb entries on free-list
12:50:53 Kernel version ioctl failed (Inappropriate ioctl for device)!
12:50:53 2.3 or later kernels require an updated kernel module!
12:50:53 Initial LRDB allocation
12:50:53 Getting Root Volume information...
12:50:54 Venus starting...
12:51:09 fatal error -- vsgent::Connect: (0) failed (-2004)
12:51:09 RecovTerminate: clean shutdown



SERVER (-d 10):
0x1016e088 : Cop Pending Manager
12:40:58 LockQueue Manager woken up
12:40:58 LockQueue Manager sleeping for 60 seconds
12:41:28 Worker 0 received request -13 on cid 981794089 for NA at NA
12:41:28 client_GetVenusId: got new host 192.168.33.1:2430
12:41:28 in AL_NameToId(System:AnyUser)
12:41:28 in AL_GetInternalCPS(-101, 0x101aa164)
12:41:28 New connection received RPCid 981794089, security lvl 98, rem id
352841080
12:41:28 Worker 1 received request 40 on cid 981794089 for root at 192.168.33.1
12:41:28 FS_ViceNewConnectFS (version 3) for user root at agrippa.venus
12:41:28 Building callback conn.
12:41:28 No idle WriteBack conns, building new one
12:41:28 Writeback message to 192.168.33.1 port 2430 on conn 1a8db4e0 succeeded
12:41:28 FS_ViceNewConnectFS returns Success
12:41:28 Worker 2 received request 15 on cid 981794089 for root at 192.168.33.1
12:41:28 ViceGetRootVolume
12:41:28 ViceGetRootVolume returns Success, Volume = coda.root
12:41:28 Worker 3 received request 24 on cid 981794089 for root at 192.168.33.1
12:41:28 ViceGetVolumeInfo volume = coda.root
12:41:28 ViceGetVolumeInfo returns Success, Volume 2130706435, type 3, servers
7f000001 0 0 0...
0x1016e088 : Cop Pending Manager