"no such item" error terminates /log print follow

RouterOS
1

Something similar was mentioned in re: ROS 6.46 five years ago (see below).

On ROS 7.23.1, I occasionally will see /tool/sniffer packet print follow operations terminate abruptly with a "no such item" error, e.g.

[admin@MikroTik3] /tool/sniffer> pack print follow
TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
24.657 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 282 0
24.749 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 218 0
24.749 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 218 0
24.75 bridge 10.0.0.5:56306 83.40.90.106:56306 udp 122 0
24.75 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 122 0
24.755 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
24.756 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
24.874 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
24.874 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
24.875 bridge 10.0.0.5:56306 83.40.90.106:56306 udp 554 0
24.875 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 554 0
25.094 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
25.094 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 122 0

no such item (4)
[admin@MikroTik3] /tool/sniffer> pack print follow
TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
29.559 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 1482 0
29.662 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
29.662 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
29.662 bridge 10.0.0.5:56306 83.40.90.106:56306 udp 714 0
29.662 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 714 0

no such item (4)
[admin@MikroTik3] /tool/sniffer> pack print follow
TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
34.588 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 1482 0
34.661 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
34.662 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 122 0
34.662 bridge 10.0.0.5:56306 83.40.90.106:56306 udp 282 0
34.662 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 282 0
34.759 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 218 0
34.759 bridge 83.40.90.106:56306 10.0.0.5:56306 udp 218 0
34.76 bridge 10.0.0.5:56306 83.40.90.106:56306 udp 122 0
34.76 ether2 10.0.0.5:56306 83.40.90.106:56306 udp 122 0
34.88 ether2 83.40.90.106:56306 10.0.0.5:56306 udp 122 0

no such item (4)

The current sniffer configuration while this packet print follow is in progress is:

[admin@MikroTik3] /tool/sniffer> print
only-headers: no
memory-limit: 100KiB
memory-scroll: yes
file-name:
file-limit: 1000KiB
streaming-enabled: no
streaming-server: 0.0.0.0:37008
max-packet-size: 2048
filter-stream: no
filter-interface:
filter-mac-address:
filter-src-mac-address:
filter-dst-mac-address:
filter-mac-protocol:
filter-ip-address: 10.0.0.5/32, 83.40.90.106/32
filter-src-ip-address:
filter-dst-ip-address:
filter-ipv6-address:
filter-src-ipv6-address:
filter-dst-ipv6-address:
filter-ip-protocol:
filter-port: 56306
filter-src-port:
filter-dst-port:
filter-vlan:
filter-cpu:
filter-size:
filter-direction: any
filter-operator-between-entries: and
quick-rows: 20
quick-show-frame: no
running: yes

.. so it doesn't seem that the sniffer should be looking for anything that might suddenly stop existing.

Am I missing something, or does this remain a RouterOS bug?

Post from five years ago:

2

I've seen this in multiple places already. can't remember exactly. But I think in some cases also a "where" was involved.

3

I could see a where clause causing this if it related to a type of object that could cease to exist on march, but in my cases there was no where, and there were no filters applied to any object types or objects that could have ceased to exist during the print follow operation.

4

When I have e.g. running this command:

/ip/firewall/connection/print interval=1s where protocol=tcp

After some time i crashes with this message:

no such item (4)