[RndTbl] wacky NFS port problem

[Trevor Cordes]

On 2016-10-24 Trevor Cordes wrote:
> It would be really nice if I could specify the local source port, or
> at least specify the list of no-no ports using this elusive,
> promised, "sysctl".  Anyone have any ideas?

Sigh... as often the case, after writing my email I found the answer,
this was a tough one!  Had to use the source patch logs to get some
hints.  I didn't want to grep the files in sys and proc for nfs, but
sunrpc.

#find /proc/ /sys/ | grep sunrpc |grep port
/proc/sys/sunrpc/max_resvport
/proc/sys/sunrpc/min_resvport

#tail -c+1 /proc/sys/sunrpc/m??_resvport
==> /proc/sys/sunrpc/max_resvport <==
1023

==> /proc/sys/sunrpc/min_resvport <==
665

Also 2 files in:
/sys/module/sunrpc/parameters/m??_resvport

Might need to tweak.

Tada!  I'll just tweak those to a tiny range I know for sure I won't use
at all, and still be under 1024.

Note, each mount takes another of those ports, so if you mount a large
number of remote fs's then you need a big enough range.  I only mount 1
NFS mount, so I'm good with a tiny (1?) range.

A bit presumptuous of them to assume anything over 665 is "safe"!!

Moral of the story, if you use NFSv4 and you run critical services over
port 664, you better set these sysctl's to avoid this problem.

Aside: I may also be forgetting my raw socket programming, but I didn't
think using a source port to connect to something external (i.e. as an
initiator) tied up that port completely keeping others from
bind/listen()ing on it?  I thought as long as you were the only
bind/listen()er it didn't matter what ports other progs took?  I could
be massively wrong on this...