Skip to content
New issue

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

IP packets stripped to 1600 when using sniff() + filter on Linux #896

Closed
gelim opened this issue Oct 18, 2017 · 3 comments
Closed

IP packets stripped to 1600 when using sniff() + filter on Linux #896

gelim opened this issue Oct 18, 2017 · 3 comments

Comments

@gelim
Copy link
Contributor

gelim commented Oct 18, 2017

Hi,
I stumbled on something strange when using sniff() and receiving IP packets with len>1600: sniff() was returning packets trimmed to 1600. By digging a bit I see that when using sniff() with custom filter that line forces the tcpdump snaplen to 1600.

How to reproduce

Sniffing part

#!/usr/bin/env python

from scapy.all import sniff
from scapy.layers.inet import IP

p = sniff(count=1, filter="host 127.0.0.1 and port 1337")[0]
print "IP.len: %d, packet len: %d" % (p[IP].len, len(p))

Sending part

>>> send(IP(dst="127.0.0.1")/TCP(dport=1337)/Raw(load=5000*'A'))
.
Sent 1 packets.

First script will give:
IP.len: 5040, packet len: 1600

Fixing

My quick patch is using already existing variable MTU:

diff --git a/scapy/arch/linux.py b/scapy/arch/linux.py
index cb95e7a..8a85ad5 100644
--- a/scapy/arch/linux.py
+++ b/scapy/arch/linux.py
@@ -136,9 +136,10 @@ def attach_filter(s, bpf_filter, iface):
     if not TCPDUMP:
         return
     try:
-        f = os.popen("%s -i %s -ddd -s 1600 '%s'" % (
+        f = os.popen("%s -i %s -ddd -s %d '%s'" % (
             conf.prog.tcpdump,
             conf.iface if iface is None else iface,
+            MTU,
             bpf_filter,
         ))
     except OSError:

Cheers dans la casa,

--
Mathieu

@p-l-
Copy link
Member

p-l- commented Oct 20, 2017

Seems all right to me, Mathieu! Care to submit a PR?

@gelim
Copy link
Contributor Author

gelim commented Oct 21, 2017

sure, #903 is on its way

@gelim gelim closed this as completed Nov 7, 2017
@gelim
Copy link
Contributor Author

gelim commented Nov 7, 2017

Thanks, I was not super reactive the last days but as PR #903 seems to be merged ok, I'm closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants