为了调试这个问题,考虑到可用的信息,我认为最好的起点是看看sendmsg是否可以返回ESRCH.首先我们需要得到你所看到的特定内核版本的源代码,我发现它是
here
经过一番挖掘,我们可以看到以下链可能会执行:
net/ipv4/udp.c:646:
err = ip_route_output_flow(&rt, &fl, sk, 1);
net/ipv4/route.c:2421:
err = __xfrm_lookup((struct dst_entry **)rp, flp, sk, flags);
net/xfrm/xfrm_policy.c:1380:
pols[1] = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_MAIN,
fl, family,
XFRM_POLICY_OUT);
net/xfrm/xfrm_policy.c:890:
err = xfrm_policy_match(pol, fl, type, family, dir);
最后,我们结束于net / xfrm / xfrm_policy.c:854:xrfm_policy_match
/*
* Find policy to apply to this flow.
*
* Returns 0 if policy found, else an -errno.
*/
static int xfrm_policy_match(struct xfrm_policy *pol, struct flowi *fl,
u8 type, u16 family, int dir)
{
struct xfrm_selector *sel = &pol->selector;
int match, ret = -ESRCH;
if (pol->family != family ||
pol->type != type)
return ret;
match = xfrm_selector_match(sel, fl, family);
if (match)
ret = security_xfrm_policy_lookup(pol, fl->secid, dir);
return ret;
}
因此,如果您检查xfrm_lookup_bytype中的代码,则会发现错误来自xfrm_policy_match,您会发现一个循环将持续到迭代器耗尽或xrfm_policy_match的返回值不是ESRCH.
这告诉我们您的sendmsg调用失败,因为您的端口没有xfrm策略.正如你所说的,它的工作原理,然后发生错误,并且持续存在这表明系统上的xfrm策略正在被调整或损坏.
从查看xfrm手册页面here可以看出,有一些工具可用于调查策略.从阅读手册页我的下一步将运行ip xfrm状态列表,当问题没有发生和发生后,比较输出.不幸的是,我没有一个2.6.24内核的运行系统来深入挖掘.
请注意,我没有任何技巧来得出这个结论,它是通过检查代码,查找和查找来确定的.这可能需要很多时间和精力,特别是当您不熟悉代码库时.为了解决这个问题而不是调试,我会尝试不同的内核版本,然后再深入挖掘.
TL; DR
看起来ESRCH错误来自称为xfrm的网络子系统,有一组用于调查xfrm的工具,可以在其手册页面here中找到
似乎很可能是错误是由于您尝试发送到的地址/端口的缺少策略.这可能是由于系统运行时的配置更改或导致xfrm策略损坏的错误.