Iain R. Learmonth | 15 Jun 15:47 2015

UDP-lite layer for Scapy


Can someone take another look at this pull request?


I really would like to have this in scapy as currently I'm having to ship a
modified scapy to get UDP-lite for my project.



e: irl <at> fsfe.org            w: iain.learmonth.me
x: irl <at> jabber.fsfe.org     t: EPVPN 2105
c: 2M0STB                  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
jérémie banier | 10 Jun 10:31 2015

Re: HTTP GET failing

Hi Hiren,

I wrote a blog post a while back after a BruCON session: http://kidcartouche.blogspot.be/2013/10/brucon-2013-scapy-or-internet-in-god.html 
It does the complete "wget" of a page, that should be enough to get you started.

Don't hesitate to come back if you have questions or comments :)

Le mer. 10 juin 2015 à 09:33, Marco Zunino <eng.marco.zunino <at> gmail.com> a écrit :
I believe you are missing the creation of TCP connection. You need first to complete the 3way handshake in order to send/receive data on a TCP stream, you do this by completing the handshake between the client and the server:

# as source TCP port, we select a random one

# prepare the SYN packet to send to server to start the handshake, note the flags=S for SYN packet

# As for TCP standard, the server side will reply with an SYN ACK packet to our SYN

# If we get a response from the server, we use the values of the SYN ACK response to assign the correct
# SEQ and ACK number of our next TCP packet (containing the HTTP REQUEST)
if syn_ack:
    request1=IP(dst=sys.argv[1])/TCP(dport=80, sport=syn_ack[TCP].dport, seq=syn_ack[TCP].ack, ack=syn_ack[TCP].seq + 1, flags='A')/httpRqs
  # We send the HTTP request and store the related ACK from the server for firther transmission
    replyAck = sr1(request)

So basically we first create a TCP connection and then we send the request on that stream, maybe google about the TCP handshake process to better understand the values assigned to SEQ and ACK numbers.

Here is the content of the HTTP request I am using:

httpRqs  = 'GET / HTTP/1.1\r\n' + \
'User-Agent: ZetaSec/1.0\r\n' + \
'Host:\r\n' + \
'Accept: */*\r\n' 

I think you might have problem with the request you are using because it is missing some mandatory HTTP Header, but that is a second step.

On Wed, Jun 10, 2015 at 2:13 AM, hiren panchasara <hiren <at> strugglingcoder.info> wrote:
Hi all,

I am on FreeBSD and scapy-2.2.0_1 and I am getting Fin back from the
server when I try to http GET an object that I know is there. (I
confirmed with wget.)

www.xyz.com/obj I want to grab. And if I do wget
www.xyz.com/obj, I do get the object. Which means, I might be
doing something wrong in the scapy commands. Here is how it looks?

ip = IP(dst="<ip of www.xyz.com>")
get = "GET /obj\r\n"

Is this not the correct way? Any pointers to debug this further?


Henrique Montenegro | 10 Jun 04:14 2015

Problem with 802.11 beacon "duplicates"

Hello list,

I asked this earlier on IRC but I figured it would probably be better to ask in the mailing list as this is easier for me and others to follow (I guess).

The following scapy script is generating 2 packages instead of a single one:

>> conf.iface = 'mon2'

>> send(Dot11(addr1='ff:ff:ff:ff:ff:ff', addr2='00:c0:ca:40:a2:66')/Dot11Beacon()/Dot11Elt(ID="SSID", info="Testing"), iface='mon2')

The packages are different, one has 5 bytes more than the other and the Rate flag set. 

I have also tried setting up the SC value to increment the sequence field, but the same issue persists. I tried adding a Dot11Elt setting the Rates as well, and I would still see one package with Rates and one without. 

I am using an Alfa AWUS051NH v2.
Same issue happens with the Alfa AWUS051H

I have setup the interfaces like this:

iw phy phy2 interface add mon2 type monitor
ifconfig wlan2 down
iwconfig mon2 mode monitor
ifconfig mon2 up
ifconfig wlan2 up

I have attached the pcap file with the two packages.

Does anyone have any idea what I might be doing wrong for this to be happening?


Attachment (scapy.pcap): application/vnd.tcpdump.pcap, 227 bytes
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org
hiren panchasara | 10 Jun 02:13 2015

HTTP GET failing

Hi all,

I am on FreeBSD and scapy-2.2.0_1 and I am getting Fin back from the
server when I try to http GET an object that I know is there. (I
confirmed with wget.)

www.xyz.com/obj I want to grab. And if I do wget
www.xyz.com/obj, I do get the object. Which means, I might be
doing something wrong in the scapy commands. Here is how it looks?

ip = IP(dst="<ip of www.xyz.com>")
get = "GET /obj\r\n"

Is this not the correct way? Any pointers to debug this further?

Robert | 29 May 13:08 2015

Scapy 2.3.1 on Windows with newest dnet and pcap

Hi all,
I've been able to successfully compile scapy dependencies and verify it
That required changes in libdnet and scapy.

Is anybody interested in instructions and patches? Where can I post them?

There's one remaining issue, though.
pcap and dnet use different naming schemes. But they provide functions to
guess the another scheme. IMO dnet does it better - pcap guesses a lot (as
stated in the original code) and possibly incorrectly.
I've fixed that in pcapdnet by relying on dnet in pcap section - in case of
missing dnet the code is still called, but with a warning.
Advantage is (should be - untested) that sniffing interfaces don't have to
have IP address.

Current code has a glitch - due to incorrect/not good enough checks if
interface name is used, the code might crash or raise incorrect exception.
For good cases it should be fine, though.

Patches and compiling instructions take up to about 400 lines - can they be
posted here? Or any other place?


To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

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 (https://github.com/tintinweb/scapy-ssl_tls) 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 scapy.ml-unsubscribe <at> secdev.org

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 diameter.py 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 https://bitbucket.org/PBattistello/scapy/ or from the secdev/scapy pull-request https://bitbucket.org/secdev/scapy/pull-request/109/diameter-layer-support-v10/diff .


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> benocs.com>
An: Adam Kułagowski <fidor <at> fidor.org>

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
http://bb.secdev.org/scapy/issues 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 l2.py:

   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/l2.py :
> ----
> 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 scapy.ml-unsubscribe <at> secdev.org

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]