NFSD problems [ long ]

Erwin J. van Eijk (eijk@huygens.org)
Fri, 06 Mar 1998 14:58:31 +0100

Hi,

Client(laura): Ultrix 4.3
Server(tommie): Linux 2.1.89-pre5 + kdev patch + socket patch
(Bleeding, bleeding edge, but stable)

If I try to mount from the server, it times out, while the server
produces the following message:

Mar 6 13:41:03 tommie kernel: nfsd: unauthenticated request from (8259b566:1694)

If I execute a exportfs client:/fs it works.

It can be traced to the following server code:

/* Validate the client's address. This will also defeat
* port probes on port 2049 by unauthorized clients.
*/
rqstp->rq_client = exp_getclient(&rqstp->rq_addr);
if (!rqstp->rq_client) {
printk(KERN_WARNING "nfsd: unauthenticated request "
"from (%08lx:%d)\n",
ntohl(rqstp->rq_addr.sin_addr.s_addr),
ntohs(rqstp->rq_addr.sin_port));
svc_drop(rqstp);
serv->sv_stats->rpcbadclnt++;
} else {
/* Process request with signals blocked. */
spin_lock_irq(&current->sigmask_lock);
siginitsetinv(&current->blocked, ALLOWED_SIGS);
recalc_sigpending(current);
spin_unlock_irq(&current->sigmask_lock);

svc_process(serv, rqstp);
}

If we follow the RPC sequence as observed by a third host:

11:46:22.836226 laura.huygens.org.1650 > tommie.huygens.org.sunrpc: udp 56
11:46:22.836774 tommie.huygens.org.sunrpc > laura.huygens.org.1650: udp 28
11:46:22.838998 laura.huygens.org.905768201 > tommie.huygens.org.nfs: 40 null
After this, nothing interesting happens.

If I trace laura mounting from another host (running nfsd-2.2B29)

11:51:51.074160 laura.huygens.org.1655 > hyper.huygens.org.sunrpc: udp 56
11:51:51.075219 hyper.huygens.org.sunrpc > laura.huygens.org.1655: udp 28
11:51:51.077273 laura.huygens.org.905598763 > hyper.huygens.org.nfs: 40 null
11:51:51.077579 hyper.huygens.org.nfs > laura.huygens.org.905598763: reply ok 24 null
11:51:51.079434 laura.huygens.org.1657 > hyper.huygens.org.sunrpc: udp 56
11:51:51.080183 hyper.huygens.org.sunrpc > laura.huygens.org.1657: udp 28
11:51:51.086250 laura.huygens.org.1018 > hyper.huygens.org.mount: udp 96
11:51:51.092847 hyper.huygens.org.mount > laura.huygens.org.1018: udp 60
11:51:51.095118 laura.huygens.org.1141803572 > hyper.huygens.org.nfs: 116 getattr [|nfs]
11:51:51.095674 hyper.huygens.org.nfs > laura.huygens.org.1141803572: reply ok 96 getattr [|nfs]
11:51:51.097122 laura.huygens.org.1158580788 > hyper.huygens.org.nfs: 116 statfs [|nfs]
11:51:51.097499 hyper.huygens.org.nfs > laura.huygens.org.1158580788: reply ok 48 statfs [|nfs]
11:51:56.157870 laura.huygens.org.1660 > hyper.huygens.org.sunrpc: udp 56
11:51:56.158905 hyper.huygens.org.sunrpc > laura.huygens.org.1660: udp 28
11:51:56.163438 laura.huygens.org.1661 > hyper.huygens.org.mount: udp 96
11:51:56.169789 hyper.huygens.org.mount > laura.huygens.org.1661: udp 24

As you can see, laura first sends a null rpc to the server to
establish the precence of the server after which laura proceeds to
communicate with the mountd.

I can reliably mount from another Linux box, because that one does not
exibit the nullcall thing. (port 880 is the mountd)

11:57:00.735106 hyper.huygens.org.664 > tommie.huygens.org.sunrpc: udp 56
11:57:00.735641 tommie.huygens.org.sunrpc > hyper.huygens.org.664: udp 28
11:57:00.736759 hyper.huygens.org.665 > tommie.huygens.org.880: S 3342081910:334
2081910(0) win 32120 <mss 1460> (DF)
11:57:00.736885 tommie.huygens.org.880 > hyper.huygens.org.665: S 3341309905:334
1309905(0) ack 3342081911 win 32120 <mss 1460> (DF)
11:57:00.737209 hyper.huygens.org.665 > tommie.huygens.org.880: . ack 1 win 3212
0 (DF)
11:57:00.737815 hyper.huygens.org.665 > tommie.huygens.org.880: P 1:113(112) ack
1 win 32120 (DF)
11:57:00.742081 tommie.huygens.org.880 > hyper.huygens.org.665: . ack 113 win 32
120 (DF)
11:57:00.744061 tommie.huygens.org.880 > hyper.huygens.org.665: P 1:65(64) ack 1
13 win 32120 (DF)
11:57:00.744791 hyper.huygens.org.667 > tommie.huygens.org.sunrpc: udp 56
11:57:00.745244 tommie.huygens.org.sunrpc > hyper.huygens.org.667: udp 28
11:57:00.745697 hyper.huygens.org.665 > tommie.huygens.org.880: F 113:113(0) ack
65 win 32120 (DF)
11:57:00.745746 tommie.huygens.org.880 > hyper.huygens.org.665: . ack 114 win 32
120 (DF)
11:57:00.745886 tommie.huygens.org.880 > hyper.huygens.org.665: F 65:65(0) ack 1
14 win 32120 (DF)
11:57:00.746086 hyper.huygens.org.665 > tommie.huygens.org.880: . ack 65 win 321
20 (DF)
11:57:00.746173 hyper.huygens.org.665 > tommie.huygens.org.880: . ack 66 win 321
20 (DF)
11:57:00.746598 hyper.huygens.org.4080928768 > tommie.huygens.org.nfs: 176 getat
tr [|nfs]
11:57:00.803430 tommie.huygens.org.nfs > hyper.huygens.org.4080928768: reply ok
96 getattr [|nfs]

Any fixes possible? The 'easy' way would be to special case the null
call. I know it would introduce a portscanning problem, but I could
care less in this case.... However, I feel a little to uncomfy with
the nfsd code to hack it myself.

Grtz
EJ

--
+--------------------+ There's only one rule:
| Erwin J.  van Eijk | 		The golden rule.
| eijk@acm.org       | He who owns the gold, rules.
+--------------------+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu