OK, thanks for clarifying. Below mail causes the misunderstanding. > > I need to add option "-f ipv4", but not all entries can be updated > > successfully. "Protocol error" is reported. > > EPROTO means netlink sequence numbers are not fine, which might refer > to another userspace bug. > > I made another patch, error handling was not robust in the -U case (no > exit_error was used, instead printf). > > Also try this patch on of the previous patch. > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821102739.4893-1-pablo@xxxxxxxxxxxxx/ Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 于2023年8月22日周二 18:00写道： > > On Tue, Aug 22, 2023 at 05:46:06PM +0800, Tony He wrote: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 于2023年8月22日周二 16:51写道： > > > > > > On Tue, Aug 22, 2023 at 10:11:00AM +0800, Tony He wrote: > > > [...] > > > > 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/ > > > > > > This is also required because conntrack -U/-D dumps the table from the > > > kernel, then it iterates over the list of entries. If the entry > > > expires, -U/-D will hit ENOENT, which should be ignored. This is > > > another regressions from 1.4.6. > > > > Sorry, I still don't quite understand. I mean if we don't add [1] and > > [2] , I can reproduce "Protocol error". > > However, after adding above [1] and [2], I can not reproduce "Protocol > > error" even though [3] is not added. > > Is [3] used to fix "Protocol error"? If yes, why it can not be > > reproduced by me? My test env is not changed. > > > > [1] https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821101751.4083-1-pablo@xxxxxxxxxxxxx/ > > [2] https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821120105.29538-1-pablo@xxxxxxxxxxxxx/ > > [3] https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230821102739.4893-1-pablo@xxxxxxxxxxxxx/ > > [1] and [2] are sufficient to fix the problems that you reported. > > [3] is a different issue that you did not report that I found while > reviewing this code.
