I got an issue report, too, that hcxpcapngtool doesn't convert a bettercap dump file to a hash file accepted by hashcat.
@undermuz : hashcat online converter as well as wpa-sec.stanev.org is running hcxpcapngtool to convert dump files

If you take a closer look at the status output of hcxpcapngtool you'll notice that only the four EAPOL messages are stored while the ESSID information is missing. An ESSID is mandatory to calculate the plain master key (PMK).
An ESSID can be present in BEACONs and PROBERESPONSE frames.
An ESSID will be present in ACTION frames of a CLIENT in case of a NEIGHBOR REPORT REQUEST
An ESSID is always present in ASSOCIATION and REASSOCIATION frames.

The difference between this types of frames:
BEACON and PROBERESPONSE frames can contain an unset ESSID or a zeroed ESSID. Both types of frames contain all(!) information about cipher and authentication management key (AKM) capabilities of an ACCESS POINT.
ASSOCIATION and REASSOCIATION frames contain exactly(!) the cipher suite and the AKM suite that will be in use on the following authentication.

@undermuz , to figure out what exactly is missing in the dump file, it would be helpful if you add it here.

@undermuz , to figure out what exactly is missing in the dump file, it would be helpful if you add it here.

pcaps.zip

Great, thanks.

To successful convert a 4way handshake to a hash file accepted by hashcat or john we need:
ESSID of the NETWORK
M1 or M3 EAPOL MESSAGE from ACCESS POINT to get the WPA Key Nonce
M2 or M4 EAPOL MESSAGE from CLIENT to get the WPA Key Nonce - mostly the M4 WPA Key Nonce of the CLIENT is zeroed and we can't use it.
Additional, the replay counter value of the EAPOL MESSAGES must match:
M1 replay counter value == M2 replay counter value
M3 replay counter value == M2 replay counter value +1
M3 replay counter value == M4 replay counter value

e.g.:
M1 replay counter value 1
M2 replay counter value 1
M3 replay counter value 2
M4 replay counter value 2

Now take a look at the invalid pcap dump file:
$ tshark -r invalid.pcap -T fields -e frame.number -e _ws.col.Time -e wlan.ra -e wlan.ta -e wlan_rsna_eapol.keydes.msgnr -e eapol.keydes.replay_counter

02........22:37:08,712138........3c:dc:bc:85:9b:49........58:d9:d5:8e:52:20........1........1
04........22:37:08,712138........3c:dc:bc:85:9b:49........58:d9:d5:8e:52:20........1........1
06........22:41:10,628828........f4:bf:80:dc:2d:bb........58:d9:d5:8e:52:20........1........1
08........22:41:10,628828........f4:bf:80:dc:2d:bb........58:d9:d5:8e:52:20........1........1
09........22:41:10,753352........f4:bf:80:dc:2d:bb........58:d9:d5:8e:52:20........3........2
10........22:41:10,753352........f4:bf:80:dc:2d:bb........58:d9:d5:8e:52:20........3........2
11........22:41:10,756447........f4:bf:80:dc:2d:bb........58:d9:d5:8e:52:20........3........2
12........22:41:10,756447........f4:bf:80:dc:2d:bb........58:d9:d5:8e:52:20........3........2
13........22:41:10,758162........58:d9:d5:8e:52:20........f4:bf:80:dc:2d:bb........4........2

As you can see, we only have EAPOL MESSAGES of type M1, M3 and M4 while M2 is missing!
The only present M4 message has a zeroed WPA Key Nonce, so we can't use it:

802.1X Authentication
Version: 802.1X-2001 (1)
Type: Key (3)
Length: 95
Key Descriptor Type: EAPOL RSN Key (2)
[Message number: 4]
Key Information: 0x030a
.... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
.... .... .... 1... = Key Type: Pairwise Key
.... .... ..00 .... = Key Index: 0
.... .... .0.. .... = Install: Not set
.... .... 0... .... = Key ACK: Not set
.... ...1 .... .... = Key MIC: Set
.... ..1. .... .... = Secure: Set
.... .0.. .... .... = Error: Not set
.... 0... .... .... = Request: Not set
...0 .... .... .... = Encrypted Key Data: Not set
..0. .... .... .... = SMK Message: Not set
Key Length: 0
Replay Counter: 2
WPA Key Nonce: 0000000000000000000000000000000000000000000000000000000000000000
Key IV: 00000000000000000000000000000000
WPA Key RSC: 0000000000000000
WPA Key ID: 0000000000000000
WPA Key MIC: fcb753f8cb81cb8c8a519d9662c949d6
WPA Key Data Length: 0

The conditions doesn't meet and hcxpcapngtool will not convert it.

@evilsocket in that case (if we got an M4, but the other EAPOL messages are missing/incomplete) hcxdumptool will request the entire 4 way handshake again, by sending a DISASSOCIATION frame with reason WLAN_REASON_DISASSOC_AP_BUSY
https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L4119
to init the ASSOCIATION process again.

In hcxlabtool I make it a bit more aggressive and transmit different reason codes, depending on what kind of EAPOL messages are received before:
WLAN_REASON_PREV_AUTH_NOT_VALID
WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT
WLAN_REASON_DISASSOC_STA_HAS_LEFT
https://github.com/ZerBea/wifi_laboratory/blob/main/hcxlabtool.c#L683

We do that until we receive a complete 4way handshake.

BTW:
An EAPOL M2 message is the most important one, because it contain unencrypted WPA/RSN information and a not zeroed WPA Key Nonce !!!!!
taken from valid.pcap:
802.1X Authentication
Version: 802.1X-2001 (1)
Type: Key (3)
Length: 117
Key Descriptor Type: EAPOL RSN Key (2)
[Message number: 2]
Key Information: 0x010a
.... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
.... .... .... 1... = Key Type: Pairwise Key
.... .... ..00 .... = Key Index: 0
.... .... .0.. .... = Install: Not set
.... .... 0... .... = Key ACK: Not set
.... ...1 .... .... = Key MIC: Set
.... ..0. .... .... = Secure: Not set
.... .0.. .... .... = Error: Not set
.... 0... .... .... = Request: Not set
...0 .... .... .... = Encrypted Key Data: Not set
..0. .... .... .... = SMK Message: Not set
Key Length: 0
Replay Counter: 0
WPA Key Nonce: 4b11aee040ab4c487a600f7282405f2a1d85de73f8b2f93a64c535d2cedc450f
Key IV: 00000000000000000000000000000000
WPA Key RSC: 0000000000000000
WPA Key ID: 0000000000000000
WPA Key MIC: 080d72fb2160d0852ed61e035e3e50c3
WPA Key Data Length: 22
WPA Key Data: 30140100000fac040100000fac040100000fac020000
Tag: RSN Information
Tag Number: RSN Information (48)
Tag length: 20
RSN Version: 1
Group Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
Group Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
Group Cipher Suite type: AES (CCM) (4)
Pairwise Cipher Suite Count: 1
Pairwise Cipher Suite List 00:0f:ac (Ieee 802.11) AES (CCM)
Pairwise Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
Auth Key Management (AKM) Suite Count: 1
Auth Key Management (AKM) List 00:0f:ac (Ieee 802.11) PSK
Auth Key Management (AKM) Suite: 00:0f:ac (Ieee 802.11) PSK
Auth Key Management (AKM) OUI: 00:0f:ac (Ieee 802.11)
Auth Key Management (AKM) type: PSK (2)
RSN Capabilities: 0x0000
.... .... .... ...0 = RSN Pre-Auth capabilities: Transmitter does not support pre-authentication
.... .... .... ..0. = RSN No Pairwise capabilities: Transmitter can support WEP default key 0 simultaneously with Pairwise key
.... .... .... 00.. = RSN PTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
.... .... ..00 .... = RSN GTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
.... .... .0.. .... = Management Frame Protection Required: False
.... .... 0... .... = Management Frame Protection Capable: False
.... ...0 .... .... = Joint Multi-band RSNA: False
.... ..0. .... .... = PeerKey Enabled: False
..0. .... .... .... = Extended Key ID for Individually Addressed Frames: Not supported

In summary, we can say it is not an issue of bettercap/pwnagotchi or hcxpcapngtool.
It is more a feature request to add a function to bettercap to initiate a new ASSOCIATION procedure as mentioned before, if the 4 way handshake is incomplete.

This warning is related to go.lang in combination with libpcap and NETLINK:
Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

e.g.: packet 3 is out of time sequence, packet 2 and packet 4 have the same time (it is impossible that 2 packets are transmitted at the same time):
$ tshark -r invalid.pcap -T fields -e frame.number -e _ws.col.Time
1 22:34:31,240591
2 22:37:08,712138
3 22:37:08,694193
4 22:37:08,712138
5 22:36:42,732392
6 22:41:10,628828
7 22:41:10,612168
8 22:41:10,628828
9 22:41:10,753352
10 22:41:10,753352
11 22:41:10,756447
12 22:41:10,756447
13 22:41:10,758162
14 22:41:28,906162
15 22:41:28,910910
16 22:41:40,156068
17 22:41:40,756959
18 22:41:40,759654
19 22:41:40,812726
20 22:41:44,272226
21 22:41:44,282599
22 22:41:44,291715
23 22:41:44,292519
24 22:41:55,679777

e.g.: packet 2 is out of time sequence, packet 4, 6, 8 and 10 have the same time.
$ tshark -r valid.pcap -T fields -e frame.number -e _ws.col.Time
1 20:44:16,261499
2 20:44:16,172058
3 20:44:16,263134
4 20:44:16,172058
5 20:44:16,264770
6 20:44:16,172058
7 20:44:16,270307
8 20:44:16,172058
9 20:44:16,271981
10 20:44:16,172058
11 20:44:17,171270
12 20:44:17,157441
13 20:44:19,456548
14 20:44:17,196130
15 20:44:19,459642
16 20:44:17,196130
17 20:44:19,461224
18 20:44:17,196130
19 20:44:19,464425
20 20:44:17,196130
21 20:44:19,467505
22 20:44:17,196130
23 20:44:19,519711
24 20:44:17,196130
25 20:44:19,521694
26 20:44:17,196130
27 20:44:19,523267
28 20:44:17,196130
29 20:44:20,179123
30 20:44:17,157441
31 20:44:20,182086
32 20:44:17,157441
33 20:44:20,184923
34 20:44:17,157441
35 20:44:20,187766
36 20:44:17,157441
37 20:56:42,810337
38 20:57:29,054055
39 20:57:29,037355
40 20:57:29,054055
41 20:57:29,569657
42 20:57:29,652834
43 20:57:29,683011
44 20:57:29,688382
45 20:57:29,691082
46 20:57:29,750057
47 20:57:29,820051
48 20:57:29,822387
49 20:57:29,824700
50 20:57:29,827090
51 20:57:30,685549
52 20:57:30,685549
53 20:57:30,688578
54 20:57:30,688578
55 20:57:30,695520
56 21:00:02,769728
57 21:00:02,775075
58 21:00:02,796016
59 21:00:02,801213
60 21:00:03,478463
61 21:00:03,814949

tshark -r /root/DISTR/bettercap/wpa.pcap -T fields -e frame.number -e _ws.col.Time -e wlan.ra -e wlan.ta -e wlan_rsna_eapol.keydes.msgnr -e eapol.keydes.replay_counter
Running as user "root" and group "root". This could be dangerous.
tshark: Lua: Error during loading:
/usr/share/wireshark/init.lua:310: attempt to call global 'get_wtap_filetypes' (a nil value)
stack traceback:
/usr/share/wireshark/init.lua:310: in main chunk
1 0.000000 c8:f7:33:0b:11:99 ac:84:c6:19:95:a6 1 1
2 0.000979 ac:84:c6:19:95:a6 c8:f7:33:0b:11:99 2 1
3 0.003934 c8:f7:33:0b:11:99 ac:84:c6:19:95:a6 3 2
4 0.004794 ac:84:c6:19:95:a6 c8:f7:33:0b:11:99 4 2

┌──(root💀kali)-[~/DISTR/bettercap]
└─#

so here I have no ESSID from pcap file generated from bettercap .
Question: is there some way to manually add information to form a file of the correct format for hashcat?
If necessary, I can attach my pcap file.

I do not recommend to add an ESSID by manually and hcxpcapngtool has no option to add an ESSID. If the ESSID doesn't match exactly, you'll waste your time trying to recover the PSK.
Your dump file doesn't contain the ESSID and important information about it, e.g.: character coding
https://seclists.org/wireshark/2018/Mar/28

It is much better to capture a new fresh 4way handshake or (better) a PMKID.

BTW:
The timestamps looking very suspicious.

To answer your question completely:
You can always assemble a 22000 hash line by hand if you pick up all values from tshark or Wireshark.

EAPOL 4way handshake hash line:
WPA*02*MIC*MAC_AP*MAC_CLIENT*ESSID*NONCE_AP*EAPOL_CLIENT*MESSAGEPAIR
get MIC from M2
get MAC_AP (destination address) from M2 and insert it into the hash line
get MAC_CLIENT (source address) from M2 and insert it into the hash line
convert the ESSID to hex and insert it into the hash line
get NONCE_AP from WPA Key Nonce M1 and insert it into the hash line
get EAPOL data from M2, zero the MIC field and insert it into the hash line
add MESSAGEPAIR: 02

hashcat will accept this hash line.

The same applies to a PMKID hash line:
WPA*01*PMKID*MAC_AP*MAC_CLIENT*ESSID***

@undermuz , this

Steps to Reproduce
1    deauth several ap

is old school and will not work if
deauthentication frames are injected between data packets (most of the APs are hardened) or
management frame protection (MFP) is activated.

@evilsocket , please take a look what happens if an AP receive a CLASS 2 or a CLASS 3 frame outside the expected AUTHENTICATION STATE. This attack vector is extreme fast and very effective.
Please take a look at:
802.11 Wireless Networks: The Definitive Guide, O'Reilly, April 2002
4.4.1 Frame Classes

This attack vector is part of hcxlabtool:
https://github.com/ZerBea/wifi_laboratory/blob/main/hcxlabtool.c#L1997
and hcxdumptool:
https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L5577
It works fine:
https://hashcat.net/forum/thread-10572-post-54489.html#pid54489
It would be great to see this attack vector in bettercap.

Another attack vector is to request an EAPOL M2 directly from a CLIENT.
That is nearly the same as requesting an EAPOL M1 (PMKID) from an AP.

@ZerBea https://twitter.com/evilsocket/status/1467884054607499275 tl;dr i'm on a long break

Hi Simone.
Thanks for the info. Take care and have fun.

Cheers
Mike