> On Jan 29, 2024, at 10:07 AM, Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote:
>
> On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
>>
>>> On Jan 29, 2024, at 6:44 AM, Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote:
>>>
>>> What would be the correct syntax to specify a custom (non-2049) TCP
>>> port for refer= in /etc/exports ?
>>>
>>> Would this work:
>>> ---- snip ----
>>> `/ref *(no_root_squash,refer=/export/home@134.49.22.111:32049)
>>> ---- snip ----
>>
>> Hello Roland -
>>
>> Although generic NFSv4 referral support has been in NFSD for
>> many years, NFSD currently does not implement alternate ports
>> in referrals.
>
> I know, but the question is about the syntax in /etc/exports. The idea
> is to use the same syntax for other NFSv4 server implementations (like
> nfs4j) ...
>
> For context: I have a ticket open for the ms-nfs41-client to get the
> referral support with custom (non-2049) TCP ports fixed...
Here's a workaround that might be used with current
versions of NFSD. I'm going to walk through this because
there is some information that could be useful for
ms-nfs41-client.
Referrals are conveyed to NFSv4 clients using the
fs_locations attribute of GETATTR. This attribute conveys
a list of alternate locations a client can use to access
the share it's looking for.
Each item in the list looks like this:
struct fs_location4 {
utf8str_cis server<>;
pathname4 rootpath;
};
The content of the server<> field is either a hostname or
an IP address. RFC 8881 Section 11.16 says:
> An IPv4 or IPv6 address is represented as a universal address (see Section 3.3.9 and [12]), minus the netid, and either with or without the trailing ".p1.p2" suffix that represents the port number. If the suffix is omitted, then the default port, 2049, SHOULD be assumed.
Therefore there is only one way to convey an alternate
port. You can't do it when the server<> field contains a
DNS label; the server has to spell it out with a universal
address. This is part of the NFSv4 protocol, it's not an
NFSD limitation.
(When NFSD supports this properly, it will need to resolve
each hostname to an IP address, when an alternate port is
present, before it builds the fs_location4 list item).
It turns out that our mountd passes the "host" part of the
refer= option to the kernel without much additional
checking, so you can specify a full IPv4 universal address
like so:
/export/referral *(refer=/export/yada@192.168.1.77 <mailto:refer=/export/yada@192.168.1.77>.8.1)
That is, it's an IPv4 address with a .p1.p2 suffix.
p1 = port DIV 256
p2 = port MOD 256
Here, .8.1 is port 2049.
I've tried some simple testing, and it seems to work with
both refer= and nfsref.
This refer= port syntax probably won't work for IPv6
addresses, and definitely will not for DNS labels. Thus
I consider this a hack and not a long-term solution for
NFSD.
Regarding Roland's question about copying this syntax for
other NFSv4 servers: I recommend that you don't do that.
You'll end up copying its mistakes and limitations. To
amplify my previous explanation: this is unfinished work,
and there are other, better ways to handle referrals.
Moreover, you can't copy what doesn't exist. Since NFSD
currently does not support alternate ports in any kind
of robust way, there's nothing to copy. Each server
implementation will have to invent their own.
--
Chuck Lever
