Troubleshooting
FAQ
I can’t sniff/inject packets in monitor mode.
The use monitor mode varies greatly depending on the platform.
Using Libpcap
libpcap
must be called differently by Scapy in order for it to create the sockets in monitor mode. You will need to pass themonitor=True
to any calls that open a socket (send
,sniff
…) or to a Scapy socket that you create yourself (conf.L2Socket
…)Native Linux (with libpcap disabled): You should set the interface in monitor mode on your own. I personally like to use iwconfig for that (replace
monitor
bymanaged
to disable):$ sudo ifconfig IFACE down $ sudo iwconfig IFACE mode monitor $ sudo ifconfig IFACE up
If you are using Npcap: please note that Npcap npcap-0.9983
broke the 802.11 util back in 2019. It has yet to be fixed (as of Npcap 0.9994) so in the meantime, use npcap-0.9982.exe
Note
many adapters do not support monitor mode, especially on Windows, or may incorrectly report the headers. See the Wireshark doc about this
We make our best to make this work, if your adapter works with Wireshark for instance, but not with Scapy, feel free to report an issue.
My TCP connections are reset by Scapy or by my kernel.
The kernel is not aware of what Scapy is doing behind his back. If Scapy sends a SYN, the target replies with a SYN-ACK and your kernel sees it, it will reply with a RST. To prevent this, use local firewall rules (e.g. NetFilter for Linux). Scapy does not mind about local firewalls.
I can’t ping 127.0.0.1 (or ::1). Scapy does not work with 127.0.0.1 (or ::1) on the loopback interface.
The loopback interface is a very special interface. Packets going through it are not really assembled and disassembled. The kernel routes the packet to its destination while it is still stored an internal structure. What you see with `tcpdump -i lo`
is only a fake to make you think everything is normal. The kernel is not aware of what Scapy is doing behind his back, so what you see on the loopback interface is also a fake. Except this one did not come from a local structure. Thus the kernel will never receive it.
On Linux, in order to speak to local IPv4 applications, you need to build your packets one layer upper, using a PF_INET/SOCK_RAW socket instead of a PF_PACKET/SOCK_RAW (or its equivalent on other systems than Linux):
>>> conf.L3socket
<class __main__.L3PacketSocket at 0xb7bdf5fc>
>>> conf.L3socket = L3RawSocket
>>> sr1(IP(dst) / ICMP())
<IP version=4L ihl=5L tos=0x0 len=28 id=40953 flags= frag=0L ttl=64 proto=ICMP chksum=0xdce5 src=127.0.0.1 dst=127.0.0.1 options='' |<ICMP type=echo-reply code=0 chksum=0xffff id=0x0 seq=0x0 |>>
With IPv6, you can simply do:
# Layer 3
>>> sr1(IPv6() / ICMPv6EchoRequest())
<IPv6 version=6 tc=0 fl=866674 plen=8 nh=ICMPv6 hlim=64 src=::1 dst=::1 |<ICMPv6EchoReply type=Echo Reply code=0 cksum=0x7ebb id=0x0 seq=0x0 |>>
# Layer 2
>>> conf.iface = "lo"
>>> srp1(Ether() / IPv6() / ICMPv6EchoRequest())
<Ether dst=00:00:00:00:00:00 src=00:00:00:00:00:00 type=IPv6 |<IPv6 version=6 tc=0 fl=866674 plen=8 nh=ICMPv6 hlim=64 src=::1 dst=::1 |<ICMPv6EchoReply type=Echo Reply code=0 cksum=0x7ebb id=0x0 seq=0x0 |>>>
On Windows, BSD, and macOS, you must deactivate the local firewall and set ``conf.iface`
to the loopback interface prior to using the following commands:
# Layer 3
>>> sr1(IP() / ICMP())
<IP version=4L ihl=5L tos=0x0 len=28 id=40953 flags= frag=0L ttl=64 proto=ICMP chksum=0xdce5 src=127.0.0.1 dst=127.0.0.1 options='' |<ICMP type=echo-reply code=0 chksum=0xffff id=0x0 seq=0x0 |>>
>>> sr1(IPv6() / ICMPv6EchoRequest())
<IPv6 version=6 tc=0 fl=866674 plen=8 nh=ICMPv6 hlim=64 src=::1 dst=::1 |<ICMPv6EchoReply type=Echo Reply code=0 cksum=0x7ebb id=0x0 seq=0x0 |>>
# Layer 2
>>> srp1(Loopback() / IP() / ICMP())
<Loopback type=IPv4 |<IP version=4 ihl=5 tos=0x0 len=28 id=56066 flags= frag=0 ttl=64 proto=icmp chksum=0x0 src=127.0.0.1 dst=127.0.0.1 |<ICMP type=echo-reply code=0 chksum=0xffff id=0x0 seq=0x0 |>>>
>>> srp1(Loopback() / IPv6() / ICMPv6EchoRequest())
<Loopback type=IPv6 |<IPv6 version=6 tc=0 fl=0 plen=8 nh=ICMPv6 hlim=64 src=::1 dst=::1 |<ICMPv6EchoReply type=Echo Reply code=0 cksum=0x7ebb id=0x0 seq=0x0 |>>>
BPF filters do not work. I’m on a ppp link
This is a known bug. BPF filters must compiled with different offsets on ppp links. It may work if you use libpcap (which will be used to compile the BPF filter) instead of using native linux support (PF_PACKET sockets).
traceroute() does not work. I’m on a ppp link
This is a known bug. See BPF filters do not work. I’m on a ppp link
To work around this, use nofilter=1
:
>>> traceroute("target", nofilter=1)
Graphs are ugly/fonts are too big/image is truncated.
Quick fix: use png format:
>>> x.graph(format="png")
Upgrade to latest version of GraphViz.
Try providing different DPI options (50,70,75,96,101,125, for instance):
>>> x.graph(options="-Gdpi=70")
If it works, you can make it permanenent:
>>> conf.prog.dot = "dot -Gdpi=70"
You can also put this line in your ~/.scapy_startup.py
file
Getting help
Common problems are answered in the FAQ.
If you need additional help, please check out:
The Gitter channel
There’s also a low traffic mailing list at scapy.ml(at)secdev.org
(archive, RSS, NNTP).
Subscribe by sending a mail to scapy.ml-subscribe(at)secdev.org
.
You are encouraged to send questions, bug reports, suggestions, ideas, cool usages of Scapy, etc.