Open hagaisela opened 4 years ago
If it works for your use case, I would recommend using the sniffer to write to a pcap and send the pcap back to test machine periodically. This would effectively batch process packets, to me it seems like you currently filter packet by packet that would mean there is a round-trip for each packet. To provide a more exact answer, I would need an example that reproduces the issue---it might be implementation dependent (i.e. round-trip latency, threading, default timeouts, etc).
Is processing a batch of packets using by sending a PCAP possible or do you have a minimal test case?
As an update, I added some debugging documentation. A PDF of the TCP stream that the exception occurs in would be helpful. If there is any concern about confidentiality, you could always encrypt it with my PGP and email under my profile.
Hi, I am trying to use rpyc alongside with scapy's AsyncSniffer. the AsyncSniffer opens a background thread which listens for packets. It also enables using a filter function for filtering packets.
I have tests running on one machine which use rpyc to connect to another machine that runs the sniffer. the packet filter runs on the test machine, not the sniffer machine.
The sequence of events is that the test machine calls start_sniffer via rpyc, this creates the scapy thread on the remote machine, then packets start arriving and each packet is filterered. meanwhile the test machine calls rx() and this waits for the scapy thread to end of the remote machine.
What I am seeing is that on some of the test runs calling the packet filter somehow triggers rx, and I can't understand why. see this stack trace:
I am using rpyc 4.1.2, and python 3.6 on ubuntu 18.04.