Searching this site(and the previous version) will give some good ideas to try:
https://osqa-ask.wireshark.org/questi... https://osqa-ask.wireshark.org/questi...
(and others)
A common source is not having a device in promiscuous mode. However, since you provided a trace, we can rule that out. I see unicast/multicast/broadcast traffic on channel 7 (an unusual channel selection for 2.4GHz, and I have never seen DTIM of 33 set before on one of the SSIDs).
Next up on the list is to make sure that the capture solutions sits within the performance envelope of the devices to be captured. This includes channel - are you sure the laptop is using the same band/channel as the monitor mode adapter.?From wikidev, that adapter is bgn 1x1:1 but your laptop, if recent, is probably more likely abgn or abgn/ac 2x2:2.
The MacBook is quite nice in terms of being able to pick up traffic, while the embedded adapter is really on the low end. So, suggest to verify all the channels in use - make sure laptop is using your configured channel 7 (turn off 5GHz on the AP if you need to) and then also dumb down the communication. You don't show successful comms collected with the MacBook so I can't say what modulations and other features are used for the EAPOL frames to know where to focus, but start by dumbing the AP all the way down (i.e. turn off 802.11n, WMM, etc) and try from there.
Also be sure the network manager is off on the Linux host - that can prevent channel changes and do other unusual things when trying to use monitor mode.
