Go-lwIP may cause memory leak about go-tun2socks HOT 5 CLOSED

另外调试过程中还发现一个现象，不知道是否与此相关。

就是若在tcp_callback_export.go中的tcpRecvFn函数中输出log，会看到core/tcp_conn.go在调用tcpConn.Close()后，会收到大量重复包，持续发送10~20s，内容类似：

[23 3 3 0 34 108 127 214 67 52 169 3 90 67 0 42 50 137 212 2 84 210 168 174 236 94 37 134 175 166 92 75 169 212 118 225 233 94 234]

在tcpRecvFn函数中会走入switch的LWIP_ERR_CLSD分支，但即便LWIP_ERR_CLSD分支里调用了C.tcp_shutdown关闭了rx侧还是会持续收到。

为何仅在close之后才会发送？是否有办法通知lwIP侧在入口处彻底不再接收这些包？感觉也是会消耗性能的

from go-tun2socks.

是否有内存泄漏我觉得你可以在桌面端测试，没必要在 IOS 上做。

leaf 使用的 lwip 跟 go-tun2socks 的在配置上不太一样，前者 lwip 配置了固定大小的 heap，后者没有使用上限，我之前测试 leaf speedtest 上传是很稳定的，go-tun2socks 必崩。

我个人已经基本不用 go-tun2socks，所以不会再去优化它，go-tun2socks 在内存和性能两方面都有缺陷，都是因为用了 Go 的关系没有简单解决办法。根据我自己的经验，我建议你不要浪费时间去把 go-tun2socks 跑在 IOS 上，因为有个 15MB 内存限制，以及 Go 的应用本来就很难控制内存使用。

from go-tun2socks.

非常感谢回复。

那我也将方向转向leaf和rust吧（虽然之前也花了不少时间研究有点可惜~_~），如果有问题我再回复。

最后想请教一下，我想研究一下lwIP（在使用层面），但不知道会不会是个坑？有什么建议吗？

from go-tun2socks.

lwip 最大的注意点是它是单线程的，如果在多线程环境使用，调用大多函数时必须用锁之类的手段做同步。

比如调用了 input 后（从这里开始加锁进入 lwip 的线程），回调函数 tcpRecvFn、tcpAcceptFn 等一般也随之被调用（这里依然处于 input 时的锁的作用范围），这是上行链路的锁。而这个就是下行链路的锁，锁 tcp_write 和 tcp_output，然后 output 回调也随之被调用。

from go-tun2socks.

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

from go-tun2socks.