Same tshark version miss http2 decodings in other machine

During decoding the same pcap file, with the same tshark version, I get different results in different machines. I thought that tshark decodes offline a pcap archive, then, I don't understand this behaviour for the same tshark version and pcap library, etc.. The part missed is the http2 decodings.

When I do

tshark -r capture.pcap -T json 

I miss all the source layers 'http2' in one machine. This is easy to see with this:

tshark -V -r capture.pcap  -Y 'http2' -T json

Because, the machine which miss http2, shows nothing for that (obviously). I could attach the capture, but I think it is not really neccessary to ask the question. It is just a pcap capture for http2 traffic.

The thing is to know what could affect the different behaviour once, every thing related to the tshark version is exactly the same ?

Note: one machine is a host, the other is a vagrant machine via VirtualBox. Both are Ubuntu Bionic.

HOST MACHINE:

tshark --version
TShark (Wireshark) 2.6.10 (Git v2.6.10 packaged as 2.6.10-1~ubuntu18.04.0)

Copyright 1998-2019 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.56.4, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua
5.2.4, with GnuTLS 3.5.18, with Gcrypt 1.8.1, with MIT Kerberos, with MaxMind DB
resolver, with nghttp2 1.30.0, with LZ4, with Snappy, with libxml2 2.9.4.

Running on Linux 4.15.0-70-generic, with Intel(R) Core(TM) i7-8650U CPU @
1.90GHz (with SSE4.2), with 32017 MB of physical memory, with locale
LC_CTYPE=en_US.UTF-8, LC_NUMERIC=es_ES.UTF-8, LC_TIME=es_ES.UTF-8,
LC_COLLATE=en_US.UTF-8, LC_MONETARY=es_ES.UTF-8, LC_MESSAGES=en_US.UTF-8,
LC_PAPER=es_ES.UTF-8, LC_NAME=es_ES.UTF-8, LC_ADDRESS=es_ES.UTF-8,
LC_TELEPHONE=es_ES.UTF-8, LC_MEASUREMENT=es_ES.UTF-8,
LC_IDENTIFICATION=es_ES.UTF-8, with libpcap version 1.8.1, with GnuTLS 3.5.18,
with Gcrypt 1.8.1, with zlib 1.2.11, binary plugins supported (13 loaded).

Built using gcc 7.4.0.

VAGRANT MACHINE:

tshark --version
TShark (Wireshark) 2.6.10 (Git v2.6.10 packaged as 2.6.10-1~ubuntu18.04.0)

Copyright 1998-2019 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.56.4, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua
5.2.4, with GnuTLS 3.5.18, with Gcrypt 1.8.1, with MIT Kerberos, with MaxMind DB
resolver, with nghttp2 1.30.0, with LZ4, with Snappy, with libxml2 2.9.4.

Running on Linux 4.15.0-65-generic, with Intel(R) Core(TM) i7-8650U CPU @
1.90GHz (with SSE4.2), with 7976 MB of physical memory, with locale C, with
libpcap version 1.8.1, with GnuTLS 3.5.18, with Gcrypt 1.8.1, with zlib 1.2.11,
binary plugins supported (13 loaded).

Built using gcc 7.4.0.

The fourth packet in my capture starts to differ. It is the first packet with HTTP2:

At host:

tshark -r capture.pcap -T json -c 4 > host.capture1-4.json

At vagrant machine:

tshark -r capture.pcap -T json -c 4 > vagrant.capture1-4.json

I put together both files:

diff host.capture1-4.json vagrant.capture1-4.json
426c426
<           "frame.protocols": "sll:ethertype:ip:tcp:http2"
---
>           "frame.protocols": "sll:ethertype:ip:tcp:data"
524,527c524
<           "tcp.payload": "50:52:49:20:2a:20:48:54:54:50:2f:32:2e:30:0d:0a:0d:0a:53:4d:0d:0a:0d:0a:00:00:12:04:00:00:00:00:00:00:02:00:00:00:00:00:04:00:40:00:00:00:06:00:a0:00:00:00:00:04:08:00:00:00:00:00:40:00:00:00",
<           "tcp.pdu.size": "24",
<           "tcp.pdu.size": "27",
<           "tcp.pdu.size": "13"
---
>           "tcp.payload": "50:52:49:20:2a:20:48:54:54:50:2f:32:2e:30:0d:0a:0d:0a:53:4d:0d:0a:0d:0a:00:00:12:04:00:00:00:00:00:00:02:00:00:00:00:00:04:00:40:00:00:00:06:00:a0:00:00:00:00:04:08:00:00:00:00:00:40:00:00:00"
529,567c526,528
<         "http2": {
<           "http2.stream": {
<             "http2.magic": "PRI * HTTP\/2.0\r\n\r\nSM\r\n\r\n"
<           },
<           "http2.stream": {
<             "http2.length": "18",
<             "http2.type": "4",
<             "http2.flags": "0x00000000",
<             "http2.flags_tree": {
<               "http2.flags.ack.settings": "0",
<               "http2.flags.unused_settings": "0x00000000"
<             },
<             "http2.r": "0x00000000",
<             "http2.streamid": "0",
<             "http2.settings": {
<               "http2.settings.id": "2",
<               "http2.settings.enable_push": "0"
<             },
<             "http2.settings": {
<               "http2.settings.id": "4",
<               "http2.settings.initial_window_size": "4194304"
<             },
<             "http2.settings": {
<               "http2.settings.id": "6",
<               "http2.settings.max_header_list_size": "10485760"
<             }
<           },
<           "http2.stream": {
<             "http2.length": "4",
<             "http2.type": "8",
<             "http2.flags": "0x00000000",
<             "http2.flags_tree": {
<               "http2.flags.unused": "0x00000000"
<             },
<             "http2.r": "0x00000000",
<             "http2.streamid": "0",
<             "http2.window_update.r": "0x00000000",
<             "http2.window_update.window_size_increment": "1073741824"
<           }
---
>         "data": {
>           "data.data": "50:52:49:20:2a:20:48:54:54:50:2f:32:2e:30:0d:0a:0d:0a:53:4d:0d:0a:0d:0a:00:00:12:04:00:00:00:00:00:00:02:00:00:00:00:00:04:00:40:00:00:00:06:00:a0:00:00:00:00:04:08:00:00:00:00:00:40:00:00:00",
>           "data.len": "64"

I can't post the whole capture (it is too much and also have sensible data). I'm a newbie here but think that stack overflow has not file hosting service.