pymumu
为 UDP 的监听端口设置 `SO_REUSEADDR`
需求应用场景
目前 openwrt 上监听的 host 为 0.0.0.0 或 [::]，且 UDP 没有设置 SO_REUSEADDR（TCP 设置了），会导致与监听端口相同的 UDP 透明代理请求失败
建议的方案
为 UDP 的监听端口设置 SO_REUSEADDR
https://github.com/v2fly/v2ray-core/issues/68
#1718 解决这个问题就可以了，其实应该算一个小bug，按理选绑定lo应该只监听127.0.0.1，但实际上始终是0.0.0.0，这样像127.0.0.1:6053这样的访问在pw的iptables规则不生效，只是因为这个是国内直连不会引起问题，smartdns如果作为透明代理的dns解析监听127.0.0.1可以避免很多问题
两个问题有一定关联但不完全一样。虽然绑定的 host 是 0.0.0.0 或 [::]，但的确对监听的接口进行了限制：https://github.com/pymumu/smartdns/blob/75649b623519dda99b772342bbbe625a45234864/src/dns_server.c#L8781-L8790
例如 bind [::]:53@lo 这条规则监听的端口是 [::]:53，但从非 lo 的接口并不能访问不到 53 端口，绑定到设备这个功能实际上是有效的，所以我觉得不算 bug。
至于你说的“绑定 lo 应该只监听 127.0.0.1”这个功能，由于规则是 luci 生成的，所以与 smartdns 本体无关
两个问题有一定关联但不完全一样。虽然绑定的 host 是
0.0.0.0或[::]，但的确对监听的接口进行了限制：https://github.com/pymumu/smartdns/blob/75649b623519dda99b772342bbbe625a45234864/src/dns_server.c#L8781-L8790
例如
bind [::]:53@lo这条规则监听的端口是[::]:53，但从非 lo 的接口并不能访问不到 53 端口，绑定到设备这个功能实际上是有效的，所以我觉得不算 bug。 至于你说的“绑定 lo 应该只监听 127.0.0.1”这个功能，由于规则是 luci 生成的，所以与 smartdns 本体无关
openwrt的实际生效的配置文件是bind:6053@lo bind :6053@lo bind :6053@lo bind :6553@lo -no-speed-check -group us -no-dualstack-selection -force-aaaa-soa -force-https-soa bind :6553@lo -no-speed-check -group us -no-dualstack-selection -force-aaaa-soa -force-https-soa 这个说明luci转换没错，只是都重复了一个，这个不知道是luci的问题还是smartdns本身的问题，然后再检查监听端口就没有127.0.0.1：6053，只有0.0.0.0：6053，也许smartdns本身内部有限制，但pw的iptables规则里确实没有流量
openwrt的实际生效的配置文件是bind:6053@lo bind :6053@lo bind :6053@lo bind :6553@lo -no-speed-check -group us -no-dualstack-selection -force-aaaa-soa -force-https-soa bind :6553@lo -no-speed-check -group us -no-dualstack-selection -force-aaaa-soa -force-https-soa 这个说明luci转换没错，只是都重复了一个，这个不知道是luci的问题还是smartdns本身的问题，然后再检查监听端口就没有127.0.0.1：6053，只有0.0.0.0：6053，也许smartdns本身内部有限制，但pw的iptables规则里确实没有流量
开了 ipv6 生成的是 bind [::]:53@lo，不开就是你的 bind :53@lo，而后者对应的 ip 就是 0.0.0.0，没有问题。要 127.0.0.1 的话对应的配置需要是 bind 127.0.0.1:53@lo
至于后面的 @lo 是传递给我上面截出来的代码段里的 setsockopt 函数的，不会影响 host 是 127.0.0.1 还是 0.0.0.0，你似乎对这一项的预期效果理解错了。
openwrt的实际生效的配置文件是bind:6053@lo bind :6053@lo bind :6053@lo bind :6553@lo -no-speed-check -group us -no-dualstack-selection -force-aaaa-soa -force-https-soa bind :6553@lo -no-speed-check -group us -no-dualstack-selection -force-aaaa-soa -force-https-soa 这个说明luci转换没错，只是都重复了一个，这个不知道是luci的问题还是smartdns本身的问题，然后再检查监听端口就没有127.0.0.1：6053，只有0.0.0.0：6053，也许smartdns本身内部有限制，但pw的iptables规则里确实没有流量
开了 ipv6 生成的是
bind [::]:53@lo，不开就是你的bind :53@lo，而后者对应的 ip 就是 0.0.0.0，没有问题。要 127.0.0.1 的话对应的配置需要是bind 127.0.0.1:53@lo至于后面的
@lo是传递给我上面截出来的代码段里的 setsockopt 函数的，不会影响 host 是 127.0.0.1 还是 0.0.0.0，你似乎对这一项的预期效果理解错了。
如果我在自定义里写bind:127.0.0.1:6053@lo，系统会报错并停止运行，实际上就是现今的代码不能实现这个功能，这个在#1718里已经提到了，按openwrt里那种处理逻辑就可以了，作为与透明代理配合使用，我觉得这算一个小bug，比如chinadns-ng就是显式指定监听端口为127.0.0.1:15353，smartdns在处理透明代理的dns解析时也这样处理就可以了，只接受特定的转发查询，因为它不需要作为整个系统的dns服务，通过指定lo来切换还能保持系统的兼容性
smartdns在处理透明代理的dns解析时也这样处理就可以了，只接受特定的转发查询，因为它不需要作为整个系统的dns服务，通过指定lo来切换还能保持系统的兼容性
我个人是喜欢把 smartdns 当作主 dns 使用的，除了分流以外他提供的其他功能也都很实用。另外如果把 smartdns 当二级 dns 用的话好像会有点小问题 https://github.com/pymumu/smartdns/issues/1743
如果我在自定义里写bind:127.0.0.1:6053@lo，系统会报错并停止运行
刚试了并不会，你写错了，bind 后面应该是空格，不是冒号 我没写错，只是在描述的时候没严格按语法来写，我截图这个是没错吧，在/var/etc/smartdns.conf这个文件里没有任何变化
smartdns在处理透明代理的dns解析时也这样处理就可以了，只接受特定的转发查询，因为它不需要作为整个系统的dns服务，通过指定lo来切换还能保持系统的兼容性
我个人是喜欢把 smartdns 当作主 dns 使用的，除了分流以外他提供的其他功能也都很实用。另外如果把 smartdns 当二级 dns 用的话好像会有点小问题 #1743
大部分透明代理软件都是基于dnsmasq，让smartdns替代它我之前试了一下是有问题的，目前我使用pw通过双端口与smartdns配合时候没有任何问题
root@OpenWrt:~# smartdns -v
smartdns 1.2024.v46.0.7
从 https://github.com/PikuZheng/smartdns/releases 下的，23.05 及之后用 openssl3
root@OpenWrt:~# smartdns -v smartdns 1.2024.v46.0.7从 https://github.com/PikuZheng/smartdns/releases 下的，23.05 及之后用 openssl3
你重启一下服务就会出问题
root@OpenWrt:~# smartdns -v smartdns 1.2024.v46.0.7从 https://github.com/PikuZheng/smartdns/releases 下的，23.05 及之后用 openssl3
你重启一下服务就会出问题
咋重启都没问题
你启动不了应该去观察日志报错
root@OpenWrt:~# smartdns -v smartdns 1.2024.v46.0.7从 https://github.com/PikuZheng/smartdns/releases 下的，23.05 及之后用 openssl3
你重启一下服务就会出问题
咋重启都没问题
你启动不了应该去观察日志报错
刚才试了一下，把smartdns替代dnsmasq再绑定一个端口可以正常运行，但如果再绑定第二服务器端口就会交替显示运行和不运行并出错，第二服务器我配置的海外组，所以目前在我的这个使用环境下无法这样做，pw强烈依赖dnsmasq，算了不折腾了，我现在这种配置运行良好
root@OpenWrt:~# smartdns -v smartdns 1.2024.v46.0.7从 https://github.com/PikuZheng/smartdns/releases 下的，23.05 及之后用 openssl3
你重启一下服务就会出问题
咋重启都没问题
你启动不了应该去观察日志报错
刚才试了一下，把smartdns替代dnsmasq再绑定一个端口可以正常运行，但如果再绑定第二服务器端口就会交替显示运行和不运行并出错，第二服务器我配置的海外组，所以目前在我的这个使用环境下无法这样做，pw强烈依赖dnsmasq，算了不折腾了，我现在这种配置运行良好
用 passwall 的 luci-smartdns-dev 分支就行，直接用 smartdns 做分流，不需要去 dnsmasq 绕一圈
root@OpenWrt:~# smartdns -v smartdns 1.2024.v46.0.7从 https://github.com/PikuZheng/smartdns/releases 下的，23.05 及之后用 openssl3
你重启一下服务就会出问题
咋重启都没问题
刚才试了一下，把smartdns替代dnsmasq再绑定一个端口可以正常运行，但如果再绑定第二服务器端口就会交替显示运行和不运行并出错，第二服务器我配置的海外组，所以目前在我的这个使用环境下无法这样做，pw强烈依赖dnsmasq，算了不折腾了，我现在这种配置运行良好
用 passwall 的 luci-smartdns-dev 分支就行，直接用 smartdns 做分流，不需要去 dnsmasq 绕一圈
这两种方式我都用过，smartdns如果做二级dns还是要经过dnsmasq，我觉得各自独立运行兼容性更好，速度也没有啥影响，smartdns分支在合并到主线之前我还是采用这种方式，因为它更新没主线快，我懒得保留两种配置编译，而且双端口转发使用模式我已有心得，目前对于我来说没有任何问题，各自的代码更新对我影响也很小