Hi Pablo, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 于2023年8月21日周一 20:02写道： > > On Mon, Aug 21, 2023 at 07:26:54PM +0800, Tony He wrote: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 于2023年8月21日周一 18:29写道： > [...] > > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821101751.4083-1-pablo@xxxxxxxxxxxxx/ > > > > This patch works when the conntrack sessions are not many. When there are about > > 300 sessions, another error "No buffer space available" is reported. > > > > Works when sessions are not many: > > root@OpenWrt:~# ./conntrack -L -p tcp |wc -l > > conntrack v1.4.7 (conntrack-tools): 204 flow entries have been shown. > > 204 > > root@OpenWrt:~# ./conntrack -U -p tcp -m 1 > [...] > > tcp 6 96 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=45714 > > dport=80 packets=7 bytes=450 src=10.40.9.83 dst=10.40.9.165 sport=80 > > dport=45714 packets=6 bytes=11265 [ASSURED] mark=1 use=2 > > conntrack v1.4.7 (conntrack-tools): Operation failed: No buffer space available > > Another patch to fix this issue, thanks for reporting: > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821120105.29538-1-pablo@xxxxxxxxxxxxx/ I confirm this issue have been fixed. I even tried about 1000 flow entries. root@OpenWrt:~# ./conntrack -L -p tcp |wc -l conntrack v1.4.7 (conntrack-tools): 1024 flow entries have been shown. 1024 root@OpenWrt:~# ./conntrack -U -p tcp -m 1 tcp 6 7423 ESTABLISHED src=192.168.1.30 dst=10.40.9.83 sport=53786 dport=80 packets=2 bytes=112 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=53786 packets=1 bytes=60 [ASSURED] mark=1 use=2 tcp 6 103 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=57656 dport=80 packets=6 bytes=398 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=57656 packets=6 bytes=11265 [ASSURED] mark=1 use=2 tcp 6 103 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=57000 dport=80 packets=7 bytes=450 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=57000 packets=7 bytes=11317 [ASSURED] mark=1 use=2 tcp 6 103 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=55730 dport=80 packets=6 bytes=398 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=55730 packets=6 bytes=11265 [ASSURED] mark=1 use=2 ...... conntrack v1.4.7 (conntrack-tools): 1023 flow entries have been updated. After above issue is fixed, I can not reproduce "-f ipv4" issue. Seems that we don't need patch https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821102739.4893-1-pablo@xxxxxxxxxxxxx/ We only need https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821101751.4083-1-pablo@xxxxxxxxxxxxx/ and https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821120105.29538-1-pablo@xxxxxxxxxxxxx/ Does it make sense at source code level? root@OpenWrt:~# ./conntrack -L -p tcp |wc -l conntrack v1.4.7 (conntrack-tools): 1027 flow entries have been shown. 1027 root@OpenWrt:~# ./conntrack -U -p tcp -f ipv4 -m 1 tcp 6 64 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=43410 dport=80 packets=7 bytes=450 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=43410 packets=6 bytes=11265 [ASSURED] mark=1 use=2 tcp 6 68 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=44160 dport=80 packets=5 bytes=268 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=44160 packets=3 bytes=172 [ASSURED] mark=1 use=2 tcp 6 63 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=39350 dport=80 packets=7 bytes=450 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=39350 packets=6 bytes=11265 [ASSURED] mark=1 use=2 tcp 6 64 TIME_WAIT src=192.168.1.30 dst=10.40.9.83 sport=45470 dport=80 packets=9 bytes=578 src=10.40.9.83 dst=10.40.9.165 sport=80 dport=45470 packets=9 bytes=13678 [ASSURED] mark=1 use=2 ...... ...... conntrack v1.4.7 (conntrack-tools): 1026 flow entries have been updated.
