hasLayer('HTTP') possible ?

[azman0101]

When I try to filter on packets where HTTP layer is present, I didn't cet any result.

Is your implementation of The HTTP LAYER handle this method ?

[invernizzi]

Hello,
sorry for the delay, I didn't see this before. haslayer() works as intended. Try to run this code in the root directory of the project.

#!/usr/bin/env python
try:
    import scapy.all as scapy
except ImportError:
    import scapy

import HTTP

packets = scapy.rdpcap('example_network_traffic.pcap')
for p in packets:
    print p.haslayer('HTTP')

[ch4174nya]

I see a similar issue.
When I sniff packets from the scapy shell and try a haslayer(SSL) on each packet, I do get desired results, confirming that haslayer() works as intended, but when I try the same using a python script, haslayer(SSL) returns false, for the same packets.
Any suggestions on what am I missing?

[invernizzi]

Hi ChaitanyaKr,
could you check if your issue is related to this scapy extension? This extension doesn't handle the SSL layer, just the HTTP one.
Let me know!

[ch4174nya]

No, you can close the issue now.
It was a scapy-tls-ssl thing. I resolved it.
Sorry to bother you.

On Mon, Jun 22, 2015 at 11:42 PM, Luca Invernizzi notifications@github.com
wrote:

Hi ChaitanyaKr,
could you check if your issue is related to this scapy extension? This
extension doesn't handle the SSL layer, just the HTTP one.
Let me know!

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

Chaitanya

[ch4174nya]

I am now making use of scapy-http, and see the same issue as the user above. Here's my setup:
I have two hosts, of which one hosts a file server. The second one tries to reach out to the server using wget (I also tried urllib2). Thirdly, I have a ScaPy sniffer operating at a switch between them.
wget requests return the desired output, the sniffer (scapy) shows me packets between the host, which look like they contain http, but haslayer returns false, and neither does packet.show() show the http layer, as it used to when I was using scapy-tls-ssl. (The fact that the communication generates http requests is also supported by Wireshark output)

[invernizzi]

Hi ChaitanyaKr,
thanks for sending me more info: now I can see what's going on.
The packet a[1].show() is the SYN packet that 10.0.0.2 sends to 10.0.0.1 as part of the three-way handshake to establish a TCP connection.
a[1] does not contain HTTP data: you can see that because the length of the IP packet is just 60; that is, the IP packet contains only an empty TCP packet.
You should see the HTTP layer in a[3] (or a[5], for some reason the packets in your screenshot seem duplicated).
Now, you are absolutely right that all these packets are part of a HTTP connection. However, not all of them contain an HTTP payload, and Scapy will respond with a[1].haslayer(HTTP) == False since, in fact, there is no HTTP layer in that specific packet.
In other words, if you had an SSH server on port 80 and you opened an SSH connection with it, the first two packets you'd send would be almost exactly a[1] and a[2]: they take care of opening the TCP connection, but they are not taking care of transporting data for the inner protocol.

That said, if you still see something weird going on, send me the tcpdump of the connection, and I'll look into it.
Ciao!

[ch4174nya]

Hi Luca,
Although my task got accomplished by looking into the "Raw" layer itself (as I needed only GET headers), I think it better to let you know that I still couldn't get a single packet that could give me a "true" on the haslayer("HTTP") check-neither did packets like a[3] or a[5], as you had suggested above.

[invernizzi]

Hi,
I'll be happy to look more into this, if you provide a pcap file.

On Mon, Jul 13, 2015 at 12:14 PM ChaitanyaKr notifications@github.com
wrote:

Hi Luca,
Although my task got accomplished by looking into the "Raw" layer itself
(as I needed only GET headers), I think it better to let you know that I
still couldn't get a single packet that could give me a "true" on the
haslayer("HTTP") check-neither did packets like a[3] or a[5], as you had
suggested above.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.