Hi, I’ll have to take a closer look, but I should warn you that using NFS over UDP is strongly discouraged. Today’s fast networks are fast enough that there can be problems with UDP packet re-assembly since the 16 bit packet ID can wrap within the lifetime of a packet resulting in fragments from older packets being reassembled with fragments of newer packets. Most of the time this cause checksum errors (which then affect performance) but it IS possible to produce data corruption if the 16 bit checksum happens to still be OK (possibly occurring for 1 in 65k packets). Frank From: Sagar Singh [mailto:sagar.it.iiests@gmail.com] Sent: Monday, April 24, 2023 11:19 PM To: devel(a)lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] UDP mount in nfs-ganesha Hi, We are trying to work on a UDP mount for ganesha, and need some feedback. For NLM lock recovery we use the node local ip address of ganesha server-node. It works perfectly fine with the TCP mount. But with the UDP mount we have seen that local rq_xprt->xp_local.nb.buf points to valid local-ip, however rq_xprt->xp_local.ss have ip address ADDR_ANY. (gdb) p *((struct sockaddr_in*)&reqdata->svc->rq_xprt-> <http://xp_local.ss/> xp_local.ss) $2 = {sin_family = 2, sin_port = 264, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"} (gdb) p *((struct sockaddr_in*)reqdata->svc->rq_xprt->xp_local.nb.buf) $3 = {sin_family = 3, sin_port = 0, sin_addr = {s_addr = 2237796106}, sin_zero = "\n\017b\205\000\000\000"} Which causes problems in lock recovery and other functionalities. We have made some changes in the initialization code of local ip: https://github.com/nfs-ganesha/ntirpc/pull/273/files Which seems to resolve the issue of the local address being ADDR_ANY and lock recovery works fine. We are not sure that :- 1. Will this fix work with all kinds of clients? 2. Will this break any existing functionalities? Any feedback will be greatly appreciated. Thanks, Sagar Singh