We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reference #1254
env: Majaro 6.6.63-1-MANJARO Ubuntu 5.4.0-195-generic and 6.8.0-49-generic
Steps to reproduce the problem:
from scapy.all import * from scapy.all import md5 from scapy.layers.eap import EAP_MD5, EAPOL EAP_RESPONSE = 2 EAP_TYPE_MD5 = 4 value = md5(pack('!B', 5) + 'password'.encode()).digest() pkts = [ Ether(src='02:00:00:00:00:01', dst='04:00:00:00:00:01') / IP(src='10.1.1.1') /UDP() / Raw('AAAA'), Ether(src='02:00:00:00:00:01', dst='ff:ff:ff:ff:ff:ff') / IP(src='10.1.1.1') /UDP() / Raw('AAAA'), Ether(src='02:00:00:00:00:01', dst='01:80:c2:00:00:03') / IP(src='10.1.1.1') /UDP() / Raw('AAAA'), Ether(src='02:00:00:00:00:01', dst='01:80:c2:00:00:03') / EAPOL(type='EAP-Packet') / EAP_MD5(code=EAP_RESPONSE, id=5, type=EAP_TYPE_MD5, value='hdkfjghkfdjghk'), Ether(src='02:00:00:00:00:01', dst='04:00:00:00:00:44') / EAPOL(type='EAP-Packet') / EAP_MD5(code=EAP_RESPONSE, id=5, type=EAP_TYPE_MD5, value='hdkfjghkfdjghkf'), Ether(src='02:00:00:00:00:01', dst='3c:7c:3f:c0:da:11') / EAPOL(type='EAP-Packet') / EAP_MD5(code=EAP_RESPONSE, id=5, type=EAP_TYPE_MD5, value='hdkfjghkfdjghkff'), Ether(src='02:00:00:00:00:01', dst='00:00:23:00:03:01') / EAPOL(type='EAP-Packet') / EAP_MD5(code=EAP_RESPONSE, id=5, type=EAP_TYPE_MD5, value='hdkfjghkfdjghkfjj'), ]
tcpdump -i enp3s0 ether proto 0x888e and inbound
sendp(pkts, iface='enp2s0')
Practical results: I see that packets are received only on the second iteration. Sometimes only the first packet that did not callback.
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 15:08:26.849026 EAP packet (0) v1, len 20 15:08:26.849271 EAP packet (0) v1, len 21 15:08:26.849451 EAP packet (0) v1, len 22 15:08:26.849668 EAP packet (0) v1, len 23 ^C 4 packets captured 8 packets received by filter 0 packets dropped by kernel
02:18:10.228578 EAP packet (0) v1, len 21 02:18:10.228770 EAP packet (0) v1, len 22 02:18:10.228999 EAP packet (0) v1, len 23 ^C 3 packets captured 4 packets received by filter 0 packets dropped by kernel
The problem is reproduced only with the inbound filter
inbound
The text was updated successfully, but these errors were encountered:
Please re-test using the -n flag to tcpdump and specify tcpdump and libpcap versions and other information as shown in the CONTRIBUTING.md file.
-n
CONTRIBUTING.md
Sorry, something went wrong.
tcpdump --version tcpdump version 4.99.5 libpcap version 1.10.5 (with TPACKET_V3) OpenSSL 3.4.0 22 Oct 2024 64-bit build, 64-bit time_t
uname -a Linux d 6.6.63-1-MANJARO #1 SMP PREEMPT_DYNAMIC Sat Nov 23 02:15:34 UTC 2024 x86_64 GNU/Linux
Flag -n not affect:
tcpdump -n -i enp3s0 ether proto 0x888e and inbound tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 18:38:21.349128 EAP packet (0) v1, len 20 18:38:21.349338 EAP packet (0) v1, len 21 18:38:21.349535 EAP packet (0) v1, len 22 18:38:21.349782 EAP packet (0) v1, len 23 ^C 4 packets captured 8 packets received by filter 0 packets dropped by kernel
As a work around i changed pcap_setfilter_linux() in pcap-linux.c, apologize for the rude decision:
pcap_setfilter_linux()
pcap-linux.c
@@ -4684,6 +4684,7 @@ pcap_setfilter_linux(pcap_t *handle, struct bpf_program *filter) * so userland filtering not needed. */ handlep->filter_in_userland = 0; + return 0; } else if (err == -1) /* Non-fatal error */ {
No branches or pull requests
Reference #1254
env:
Majaro 6.6.63-1-MANJARO
Ubuntu 5.4.0-195-generic and 6.8.0-49-generic
Steps to reproduce the problem:
Practical results:
I see that packets are received only on the second iteration. Sometimes only the first packet that did not callback.
The problem is reproduced only with the
inbound
filterThe text was updated successfully, but these errors were encountered: