Open marten-seemann opened 4 years ago
How was this completed?
It wasn't, just an automatic cleanup. Reopened and will take a look.
It appears to work fine until it reaches the actual cut-off packet. I think that even if we raise a more specific exception, we should still raise one (at least by default), as ignoring cut packets might be more confusing or even not the desired effect. You can see the same error that wireshark produces if you run with debug=True
Using Pyshark 0.5.2 built from source, can confirm that issue is still around. My code:
def monitor_pyshark(device):
cap = pyshark.LiveRingCapture(
interface=device,
bpf_filter="udp",
use_json=True,
use_ek=True,
include_raw=True,
ring_file_size=1024 * 20,
num_ring_files=3
)
try:
cap.apply_on_packets(packet_callback_pyshark)
except KeyboardInterrupt:
exit(0)
Playing with the ring file parameters does not affect the output. When such a setting is used, the last packet of a network flow is systematically held in buffer until more packets arrive.
This is a snippet of a QUIC monitoring application I'm developing. The first screenshot shows what a small flow outputs. The second screenshot shows the same output when using other sniffers (e.g. scapy) or once another network flow arrives with Pyshark. In the first screenshot, the APPLICATION_CLOSE frame is missing.
I've debugged in every possible way, but obtained no relevant information about what is happening about that packet.
pyshark throws an exception when reading a pcap that cuts a packet in half. For reference, Wireshark displays the following error message when opening the file: "The capture file appears to have been cut short in the middle of a packet."
The following trace can be used to reproduce the error: trace.pcap.zip (Github doesn't allow me to upload a pcap, so please unzip it).
pyshark crashes saying