Shuoling Deng | 16 May 13:30 2015

rdpcap nflog pcap


Until scapy 2.3.1, it seems that the nflog pcap could not be parse though the rdpcap API.

 >>> a = rdpcap("/tmp/port-10000-new.pcap")
WARNING: PcapReader: unknown LL type [239]/[0xef]. Using Raw packets

If so,

Is this feature in the roadmap in scapy?

where to hack if I want to do these?


Shuoling Deng
Dept. of Computer Science and Technology
Xi'an Jiaotong University
Xi'an, 710049, P.R. China

Hubert Strauß | 3 May 20:23 2015

Modify SSL packets

currently I am trying to modify SSL Client Hello packets that are sent 
from client A to server B.
I have set up iptables to move packets into nfqueue:
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j NFQUEUE
Here is the definition of the callback function for the received SSL 
def callback(i,payload):
   data = payload.get_data()
   pkt = IP(data)

   if pkt.haslayer(SSLv2ClientHello):


So far everything works fine, if I create a SSL connection between A and 
B, the packets get redirected through the nfqueue. If the Client Hello 
shows up, it will be displayed. It should also be noted that I use the 
scapy-ssl_tls library ( to 
get a SSL layer for scapy.
But displaying Client Hello is not everything I want to do, I actually 
want to modify it. So I tried the following:
def callback(i,payload):
   data = payload.get_data()
   pkt = IP(data)

   if pkt.haslayer(SSLv2ClientHello):

   ret = payload.set_verdict_modified(nfqueue.NF_ACCEPT, str(pkt), 
   print ("ret = {}".format(ret))

This should not modify the packet at all. Basically I just use 
set_verdict_modified instead of set_verdict. I used this simple test to 
see if the method that I will need later on, for real modification, 
works. Also there is no need to recompute the length or checksum (at 
least I think so). But now the trouble begins, If I create a SSL 
connection between A and B, the connection will not be established. The 
method returns "88" (I could not find a source to figure out what that 
means) and Wireshark shows a lot of TCP Retransmissions for Client Hello.

My guess is that the packet gets modified somehow and therefore a manual 
forward (set_verdict_modified) does not work, whereas the automatic 
forwarding (set_verdict) does work because the packet is not modified. 
Hopefully someone can help me with this quite specific problem.

Best regards,

To unsubscribe, send a mail to <at>

James Woolley | 27 Apr 22:32 2015

Beacon Frame Filter

I'm having some difficulty creating a filter for the sniff function which allows me to capture only 802.11 beacon frames.

I understand that i can send each packet to a function and check if the packet.subtype == '8L'. But the code I'm writing is to be run on a RaspPi and so would be more beneficial to have the filter applied at the lower level, and so reduce the amount of resources used.

Any format of filter i try results in a Scapy_Exception("Filter parse error").

Thank you in advance for any assistance provided.
patrick.battistello | 21 Apr 10:51 2015

Diameter layer support v1.0

Hi all,


I added to the contrib directory the new file which supports Diameter protocol decoding and generation. It currently supports more than 40 Diameter commands and 550 AVPs. This file can be fetched here or from the secdev/scapy pull-request .


Most of this file has been built automatically by parsing through IETF and ETSI/3GPP standards, so please report any bug you may find in commands/AVPs support.


Next step will be to provide a ‘uts’ file. Then I will try to extend the AVPs support while not increasing too much the number of classes (currently each AVP is mapped to a class and the same holds for commands). Any suggestion or comment is welcome.


Many thanks to Guillaume Valadon for his help in setting my BitBucket/Mercurial configuration.




_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Marcel Patzlaff | 8 Apr 12:09 2015

Fwd: Re: ISIS in SCAPY and Jumbo frames

Forwarded emails regarding Jumbo LLC:

-------- Weitergeleitete Nachricht --------
Betreff: Re: ISIS in SCAPY and Jumbo frames
Datum: Wed, 08 Apr 2015 10:45:12 +0200
Von: Marcel Patzlaff <mpatzlaff <at>>
An: Adam Kułagowski <fidor <at>>

Hi Adam,

great to hear, that the extension is of use for you. Currently, we are
also experimenting with some Cisco routers and have seen those Jumbo LLC 

It think a fix like yours is quite easy to apply. But I also see a
problem because Jumbo LLC is still not really a standard. So I don't
know if a patch like this will get accepted.

I suggest that you create a ticket for this at as this is not directly an IS-IS
issue. Nevertheless, I will also have a look into scapy but I'm pretty
sure, that you already found what needs to be added to

   bind_layers(Ether, LLC, type=34928)

Kind regards,

Am 07.04.2015 um 21:54 schrieb Adam Kułagowski:
> Hi,
> First of all - thank you for ISIS extension for Scapy - it's a life
> saver :)
> However I've found that Scapy does not dissect properly ISIS packets
> from Cisco ASR9k router. The only difference is that Cisco is using
> Ethertype 0x8870 (Jumbo frames). Such packet is seen by Scapy as an
> unknown one.
> I'm far from being a programmer but the following addition to
> scapy/layers/ :
> ----
> bind_layers( Ether,         LLC,           dst='09:00:2b:00:00:05',
> type=34928)
> ----
> ...get things going again.
> I'm attaching the PCAP with such packet if you would like to take a
> closer look.
> If it's possible to add support for ISIS+Jumbo frames in your next
> release - it would be great :)
> Maye this effect can be achieved in different way - I'm afraid my Scapy
> knowledge is severely limited. If this the case - please say so.
> Best regards,
> Adam

To unsubscribe, send a mail to <at>

David Smith | 25 Mar 22:48 2015

igmpv3 module question

having some issues figuring out the proper configuration of various packets; 

for example this one, the dest address gets sent to loopback instead of the sending interface IP (which has the ether src="" mac as defined)

any help is appreciated.



import scapy.contrib.igmpv3


a=Ether(dst = "01:00:5e:00:01:01", src="00:1e:c9:5a:6b:ae")



c.srcaddrs = ['', '']

c.srcaddrs += ['']

c=scapy.contrib.igmpv3.IGMPv3(type=0x22, gaddr="")

print "Joining IP " + c.gaddr + " MAC " + a.dst

sendp(a/b/c, iface="em2")





[root <at> qa-05 ~]# tshark -V -i p8p1

Running as user "root" and group "root". This could be dangerous.

Capturing on 'p8p1'

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0

    Interface id: 0

    Encapsulation type: Ethernet (1)

    Arrival Time: Mar 24, 2015 14:23:42.398555000 PDT

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1427232222.398555000 seconds

    [Time delta from previous captured frame: 0.000000000 seconds]

    [Time delta from previous displayed frame: 0.000000000 seconds]

    [Time since reference or first frame: 0.000000000 seconds]

    Frame Number: 1

    Frame Length: 60 bytes (480 bits)

    Capture Length: 60 bytes (480 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ip:igmp]

Ethernet II, Src: 2wire_5a:6b:ae (00:1e:c9:5a:6b:ae), Dst: IPv4mcast_00:01:01 (01:00:5e:00:01:01)

    Destination: IPv4mcast_00:01:01 (01:00:5e:00:01:01)

        Address: IPv4mcast_00:01:01 (01:00:5e:00:01:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)

    Source: 2wire_5a:6b:ae (00:1e:c9:5a:6b:ae)

        Address: 2wire_5a:6b:ae (00:1e:c9:5a:6b:ae)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: IP (0x0800)

    Padding: 000000000000000000000000000000000000

Internet Protocol Version 4, Src: (, Dst: (

    Version: 4

    Header length: 20 bytes

    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))

        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)

        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)

    Total Length: 28

    Identification: 0x0001 (1)

    Flags: 0x00

        0... .... = Reserved bit: Not set

        .0.. .... = Don't fragment: Not set

        ..0. .... = More fragments: Not set

    Fragment offset: 0

    Time to live: 1

        [Expert Info (Note/Sequence): "Time To Live" only 1]

            [Message: "Time To Live" only 1]

            [Severity level: Note]

            [Group: Sequence]

    Protocol: IGMP (2)

    Header checksum: 0x7876 [correct]

        [Good: True]

        [Bad: False]

    Source: (

    Destination: (

    [Source GeoIP: Unknown]

    [Destination GeoIP: Unknown]

Internet Group Management Protocol

    [IGMP Version: 3]

    Type: Membership Report (0x22)

    Header checksum: 0xfcfd [correct]

    Num Group Records: 257

[Malformed Packet: IGMP]

    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]

        [Message: Malformed Packet (Exception occurred)]

        [Severity level: Error]

        [Group: Malformed]


mahdieh Shahverdi | 17 Mar 07:19 2015

Re: split a url into multiple packets using scapy

Thanks but I means as below:
suppose this long url :,user_religion_politics,user_relationships,user_relationship_details,user_hometown,user_location,user_likes,user_activities,user_interests,user_education_history,user_work_history,user_online_presence,user_website,user_groups,user_events,user_photos,user_videos,user_photo_video_tags,user_notes,user_about_me,user_status,friends_birthday,friends_religion_politics,friends_relationships,friends_relationship_details,friends_hometown,friends_location,friends_likes,friends_activities,friends_interests,friends_education_history,friends_work_history,friends_online_presence,friends_website,friends_groups,friends_events,friends_photos,friends_videos,friends_photo_video_tags,friends_notes,friends_about_me,friends_status&fb_sig_country=bg&fb_sig_api_key=9f7ea9498aabcd12728f8e13369a0528&fb_sig_app_id=177509235268&fb_sig=1a5c6100fa19c1c9b983e2d6ccfc05ef

I want to split this url into three tcp segment and send each tcp segment as a separate packet.
How should I do it?

On Monday, February 16, 2015 4:37 PM, Marco Zunino <eng.marco.zunino <at>> wrote:

I think a good article on the topic is the following

There are 3 post in total, first two address the theory behind fragmentation and checksum, the third one shows you the concrete example in Scapy. To be honest with you, I did not read fully the article, but at first impression looks like good information, worst case this should be at least a good starting point.

Let us know if have luck, I will check further the topic and play with the code later

On Mon, Feb 16, 2015 at 12:44 PM, mahdieh Shahverdi <m.shahverdi <at>> wrote:
I means a long URL as application data that may be store in multiple TCP segments each of them makes a IP packet.

On Monday, February 16, 2015 2:59 PM, Tobias Mueller <muelli <at>> wrote:

On Mon, Feb 16, 2015 at 11:11:43AM +0000, mahdieh Shahverdi wrote:

> Hi,How to split a url into multiple IP packets using scapy?

I'm confused. What does it even mean to have a URL in IP packets?


To unsubscribe, send a mail to <at>

newlog | 10 Mar 12:00 2015

Error injecting traffic from Windows (libdnet / scapy issue)

Hi all,

I've been trying to inject traffic from pcap files to the network. I've
been lucky on some environments, but I haven't in many others. I usually
get the following error:

> WARNING: No match between your pcap and dnet network interfaces found.
> You probably won't be able to send packets. Deactivating unneeded
> interfaces and restarting Scapy might help.

My code is as simple as:

> packets = sniff(offline=self.PCAPFileName)
> sendp(packets)

I think I've read all the information available for this issue. A
overview of the topic by Dirk here:

I know that the problem happens in scapy/arch/windows/

> def load_from_dnet(self):
>         """Populate interface table via dnet"""
>         for i in pcapdnet.dnet.intf():
>             try:
>                 # comment...
>                 if i["name"].startswith("eth") and "addr" in i:
>           [i["name"]] = NetworkInterface(i)
>             except (KeyError, PcapNameNotFoundError):
>                 pass
>         if len( == 0:
>             log_loading.warning("error")

So I don't have a clue why intf() returns an empty object in the
problematic systems. I've have all IPs setted statically. It's really
weird because it doesn't work in Windows 7 x64, but works correctly on
Windows 2012 R2 x64, so it's not because the 32 vs 64 bits.

I know that this is a libdnet bug, but given that libdnet code seems to
be abandoned and scapy relies on it for such critical things as getting
OS NICs, how's that in 5 years no workarounds have been looked? Don't
want to sound as an asshole (my english deficiencies here!)! It's just
one thing that bugs me. Is it because lack of time/resources? Because
really few people is affected by this issue? Is it really hard to solve?

I've also read that previous tries to move away from libdnet and use
WinPcap have been done (from 2009):

I guess that this didn't get to mainstream, isn't it? It would be
awesome given that WinPcap is an active project not as libdnet.

Finally, if there's no solution for this issue and, therefore, for
injecting pcap traffic from a Windows box using scapy, which are the
remaining approaches (using python)? I've been trying to look for any
other solutions, but it seems that everything boils down to libdnet or
Unix platforms (that aren't an option for me).
Does this mean that no one reliably injects traffic on windows machines
using python scripts? :)

Thanks for your great work with scapy. It really is an amazin tool.

P.S.: I've just read this:

Compiling lidbnet is a nightmare! I've tried it and I ended up using the
packages from this repo (for py2.7 and x64):

I guess I'll have to try harder to compile libdnet!

To unsubscribe, send a mail to <at>

Darren McDonald | 4 Mar 11:52 2015


Does scapy support MPLS? I want to generate sendp(Ether()/IP()/ICMP()) 
packets, but include one or more MPLS shim labels between layers 2 and 
3. I've had a look around on google and the answer seems to be no. If 
not, id appreciate any tips or guidance on how I might go about 
implementing this myself.

Best regards,


To unsubscribe, send a mail to <at>

Todd Bezenek | 17 Feb 23:21 2015

How to receive packets through netfilter/iptables into scapy?

I'm debugging a DNS firewall which uses netfilter/iptables.

I can send DNS requests which are processed by the firewall by setting:

However, when scapy gets a reply from the DNS (server), netfilter/iptables 
does not see the traffic.

Is there a way to do this?  Having scapy NOT listen would work fine as a 

Thank you for any help,

bezenek <at>

To unsubscribe, send a mail to <at>

mahdieh Shahverdi | 16 Feb 12:11 2015

split a url into multiple packets using scapy

How to split a url into multiple IP packets using scapy?