Scapy receives only first 150 replies when the native super sockets are in use #4531
Comments
GD1200
changed the title
|
As far as I can see, the problem was first introduced with commit This can be proved with the following method: When the 1-commit-before version is installed (2.4.3rc1.dev31), the problem is not manifested: It is worth mentioning, that |
|
You're right that's ugly. I'm however unsure of what's happening here. |
|
The problem gets worse with the following commit: Below is the output showing that after commit If we go one commit back, we get into a bad situation, when only 600-700 first replies are received: the effect of the previously mentioned commit |
|
Thanks for your issue. Could you please check, if you receive more packets, if you increase the timeout. I would like to understand, if the packets are "at least" in the kernels socket and scapy (python) just hadn't enough time to read them (maybe because of some slowness in LibPCAP uses PACKET_MMAP internally, afaik. This might reduce the number of syscalls to the kernel quite alot. |
|
Right, @polybassa, I forgot to mention that changing the timeout does not have any effect. For example, I get the same results even if timeout is one minute: |
To be more precise, the second regression happened at commit 0fa7d3f (2.4.3.dev227): To summarise, with my kernel 6.10.6, I observe the following: |
|
I quickly looked into it. I can confirm the issue on my system. I'm receiving exactly 147 packets, as well. I checked So it's rather something "memory" related. I also receive all the packets over wireshark. So the kernel gets them and everything seems complete. |
|
I did the following two tests to verify that the issue is not in the dissection of the Packet or in the answer and hashret function: import threading
import time
import pytest
from scapy.layers.inet import ICMP, IP
from test.testsocket import TestSocket
def test_icmp():
sender = TestSocket(ICMP)
receiver = TestSocket(ICMP)
sender.pair(receiver)
def answering_machine_thread():
def answer(pkt):
resp = ICMP(type="echo-reply", seq=pkt.seq)
receiver.send(resp)
receiver.sniff(timeout=2, prn=answer, count=1000)
sim = threading.Thread(target=answering_machine_thread)
try:
sim.start()
time.sleep(1)
pkts = sender.sr(ICMP(seq=(1,1000)), timeout=1)
print(pkts)
finally:
sim.join(timeout=5)
def test_ip():
sender = TestSocket(IP)
receiver = TestSocket(IP)
sender.pair(receiver)
def answering_machine_thread():
def answer(pkt):
resp = IP(dst=pkt.src, src=pkt.dst)/ICMP(type="echo-reply", seq=pkt.seq)
receiver.send(resp)
receiver.sniff(timeout=2, prn=answer, count=1000)
sim = threading.Thread(target=answering_machine_thread)
try:
sim.start()
time.sleep(1)
pkts = sender.sr(IP(dst='111.111.0.1')/ICMP(seq=(1,1000)), timeout=1)
print(pkts)
finally:
sim.join(timeout=5)Both test receive 1000 pkts. |
|
(I assume) This should also demonstrate that the |
|
If you run sr with threaded=True, the issue isn't present. |
@polybassa, I tried it before, and the result was indeed better. However, there were still a lot (>50%) of unseen answers on a machine with 4 physical cores / 8 threads: |
|
I also noticed that with disabled multithreading, I can normally get ~100 more packets in the threaded sr() mode: |
|
Ok, thanks. I was only testing against my router on a physical network. So the "simulated" network might send faster and therefore still cause the packet loss. But at least, we know that the issue is related to python threading. Could you do a quick test with bandwidth limitation? I wonder, at which point you would receive 100% if you step by step increase the bandwidth limitation on your virtual network. |
|
Clearly the issue here is with Scapy. I can personally easily reproduce using the script provided by OP. |
After I had shaped my transmission, I noticed changes. Namely, when I shape my TX to 128Kbps, I see all 1k answers registered in threaded mode: I also noticed improvements in the default mode mode: If I increase the HTB shaper to 256Kbps, I start seeing issues: |
|
fixed by #4538 Thanks again for the report ! |
|
Great job, @polybassa and @gpotter2! Thank you so much for fixing this so swiftly! |
Brief description
When default native super sockets are used in Linux, Scapy receives only first 150 answers while packet dump confirms that no drops take place. The problem gets solved when libpcap sockets are activated. For example:
The problem is reproducible with both the latest stable version
2.5.0and the development one2.6.0rc2.dev2.To replicate the problem, I used the following local Linux setup:
The icmp.pcap.gz dump contains 2000 packets collected while
sr()was executed against native super sockets.Thank you.
Scapy version
2.6.0rc2.dev2
Python version
3.12.5
Operating system
Linux 6.10.6
The text was updated successfully, but these errors were encountered: