Seen on Redhat-7 with distribution version of python-cryptography
(1.3.1):
  File "/usr/lib/python2.7/site-packages/scapy/layers/tls/crypto/ffdh.py", line 207, in <module>
    params = pn.parameters(default_backend())
AttributeError: 'DHParameterNumbers' object has no attribute 'parameters'

This is due to an API change in cryptography 1.7 which is the required version
for scapy. Althought, we should still be able to launch the shell.

Check if cryptography is valid before filling FFDH_GROUPS.

Signed-off-by: Thomas Faivre <thomas.faivre@6wind.com>

The ICV size is defined by the authentication algorithm in the SA.
it can be deduced from the payloadlen field but the padding len is
unknown aswell so there is no way to find both without the SA.

Assume everything in payloadlen is the ICV until the verification called
from the SA. Fill padding when possible.

Signed-off-by: Thomas Faivre <thomas.faivre@6wind.com>

[appveyor] Fix tests automaton

Only read version from git when in scapy

* Add message field in EAP-Indentity request

EAP-Identity request may contain message as stated in RFC3748.

* Fix fragmented EAP-TLS

Current implementation fails to dissect fragmented EAP-TLS.
Fragmented EAP-TLS messages are quite common, in this case only
first EAP-TLS will contain tls_message_len field (indicated by L bit),
which will be total length of reassembled tls message.

Length of tls payload in single EAP-TLS message should therefore
be determined by EAP.len field (see RFC5216-Fragmentation).

To implement this I find reasonable to make EAP-TLS subclass of EAP.

* Fix fragmented EAP-FAST

Implementation of EAP-FAST suffers from the same issue as EAP-TLS,
see previous commit message.

* Fix EAP-MD5 Dissection

Implementation of EAP-MD5 was not following RFC3748 (which is
referencing RFC1994) properly.

Field value_size is determining only size of value_field.
It might have length different than 16B in EAP-MD5 request,
because in that case it is not used to transmit MD5 hash,
but random challenge value.
Size of optional_name(extra data) is determined as "rest of" EAP message
(len field of EAP).

Scapy may be used as third party library by other projects, themselves
managed under git. This leads to surprising results such as this:

    $ git describe
    awesomeproject-v5.22-1-ga1316614c290
    $ virtualenv env
    ...
    $ . env/bin/activate
    (env)$ pip install scapy==2.3.3
    ...
    (env)$ cat env/lib/python2.7/site-packages/scapy/VERSION
    2.3.3
    (env)$ which scapy
    /home/.../env/bin/scapy
    (env)$ scapy
    ...
    Welcome to Scapy (awesomeproject-v5.22.dev1)
    >>>

Scapy's version is wrongly set to the current project's version.

When trying to determine scapy's version from git, make sure that the
code is executed from the root of a git repo. If not, read the version
from the scapy/VERSION file which has been generated when packaging
scapy source archive.

Fixes: 4f71027f ("enhance version management")
Signed-off-by: Robin Jarry <robin.jarry@6wind.com>

Prevent sr() tests crashes

[convergence] Python 3- string byte tag

[Windows] support Npcap

NTP : update and small fixes

Create a secdev team in AppVeyor

[rewritten] PR #182

[coverage] Tests for ManufDB + Multiple fixes

[Pickling] Add packets pickling support