Installation fix in #19 was not uploaded to PyPI

[weatherman2095pro]

The bugfix 71722fa in #19 meant to make the http-layer install properly on python3 and python2 has not been propagated to PyPI, such that pip3 install scapy-http still results in the same error which as been noted as fixed.

pip3 install git+https://github.com/invernizzi/scapy-http@df0caa6f38a88e45f64dff0bb3cdfaceee270ae2

The above command meanwhile has the intended results.

[gpotter2]

Please note that Scapy-python3 (Scapy3k) is nowadays quite outdated...

Scapy3k is a one-man project, which now is nothing but an outdated fork of scapy. Since its latest version, the official (and original version of scapy) fully supports Python 3 (even better than scapy3k), and contains a huge amount of bug fixes.

You might want to consider switching to Scapy

[weatherman2095pro]

On Wed, 21 Mar 2018 17:36:20 +0000 (UTC) Gabriel Potter ***@***.***> wrote: Please note that Scapy-python3 (Scapy3k) is nowadays quite outdated... Scapy3k is a one-man project, which now is nothing but an outdated fork of scapy. Since its latest version, the official (and original version of scapy) fully supports Python 3 (even better than scapy3k), and contains a huge amount of bug fixes. Please consider avoiding it scapy3k:  scapy: 

Right, thanks for the info. In the time since I posted this issue I've found that some setup.py magic could make it work properly. Nevertheless, I've run into performance issues that are making me reconsider my library choice. On profiling it seems like more time is spent inside core scapy facilities than anything related to my code specifically. Is there a way to speed up Scapy massively by disabling analysis of anything except what's needed or would one essentially need to resort to thin libpcap wrappers and external analysis libraries?

[gpotter2]

We are currently finishing release 2.4.0, which provides python 3 support, (+tons of bug fixes) meaning all new features are stuck. The release should be triggered during next week. There are awaiting PRs with massive speeding up options that are awaiting, and will get finished/merged once 2.4.0 is out, to be in 2.4.1 Among them is multithreading sniffing (speeds up x3 sniffing time) secdev/scapy#1259, and send/receiving improvement (divide loading time of the `sr` suite by 2 secdev/scapy#1142). We have other ideas (better cache implementation), which should also come out in the future. Hope I answered the question :)

…

Le 24 mars 2018 à 05:12, weatherman2095 ***@***.***> a écrit : On Wed, 21 Mar 2018 17:36:20 +0000 (UTC) Gabriel Potter ***@***.***> wrote: > Please note that Scapy-python3 (Scapy3k) is nowadays quite outdated... > > Scapy3k is a one-man project, which now is nothing but an outdated > fork of scapy. Since its latest version, the official (and original > version of scapy) fully supports Python 3 (even better than scapy3k), > and contains a huge amount of bug fixes. > > Please consider avoiding it > > scapy3k: >  > scapy: >  > > Right, thanks for the info. In the time since I posted this issue I've found that some setup.py magic could make it work properly. Nevertheless, I've run into performance issues that are making me reconsider my library choice. On profiling it seems like more time is spent inside core scapy facilities than anything related to my code specifically. Is there a way to speed up Scapy massively by disabling analysis of anything except what's needed or would one essentially need to resort to thin libpcap wrappers and external analysis libraries? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[gpotter2]

I will however note your very interesting point, about disabling everything but the needed packets..

[weatherman2095pro]

Bugfix enforces an outdated dependency, now that plain Scapy supports Python3 just fine there is no need to act on this issue.